Relationship security in online social and professional networks and communities

ABSTRACT

A method for evolving a defined online existing relationship between two members, the online existing relationship defined by a plurality of existing relationship features to manage network interaction on a communications network between the two members. The method includes receiving a new online relationship having new relationship features different from existing relationship features and characteristic of the new relationship; aggregating the existing and new relationship features as aggregate relationship features to define an aggregate relationship; storing the aggregate relationship features as relationship data; and accessing the relationship data to determine whether a selected network interaction from one of the members is permitted in view of at least one of the corresponding aggregate relationship features, and facilitating the selected network interaction when permitted; wherein the corresponding aggregate relationship features include at least one of the network interaction type, the network interaction content, or the network interaction format.

CROSS REFERENCE TO RELATED APPLICATION

This application claims the benefit of U.S. Provisional Application No.61/272,010, filed Aug. 6, 2009, now pending, the entire contents ofwhich is hereby incorporated herein by express reference thereto.

FIELD OF THE INVENTION

This invention relates to configuration of networked entities forcoordination of interaction between the networked entities.

BACKGROUND OF THE INVENTION

In today's multifaceted society, there are a number of industries (e.g.healthcare) that can be characterized as having a particularlyfragmented workforce—in healthcare from physicians to nurses to practiceadministrators—that are extremely busy in their day to day activities.Day to day work for individuals in today's industries can be highlyirregular and unpredictable, and with so many different parts working inisolation there are limited opportunities for people to be exposed toone another. Further, with few networks supporting these people orgroups in reaching out and connecting with each other, it's easy forthem to become isolated. All of this makes it very difficult forindustry professionals to get in touch with who they want when they needto, to stay in touch with colleagues and co-workers within and/orbetween different industries, and to coordinate productive interactionswith each other.

Social and professional networking is valuable to business professionalsand healthcare professionals of all types. When people become members ofsocial and professional online networks, they need to connect with othermembers in order to share information with, interact with, and networkthrough those members. In cases where people are connecting to businessprofessionals, business relationships are important and need to beentered into with care. Each relationship is different, eachrelationship has a level of trust, and people do not want to connectonline with each of their professional contacts in the same way.Ultimately, it's not a one size fits all world when it comes toconnecting online and the representation electronically (i.e. online) ofthe mixture of real world business and professional relationships isproblematic using today's electronic relationship models.

Accordingly, in the current one size fits all world, a system is neededthat enables community members to connect with their businessconnections in a way that represents their multifaceted life with theplurality of other members in the community (both known and unknown tothe community member) because the members do not want to share the sameinformation, communicate and interact in the same way, nor enable peopleto network through them in the same way, in view of real-worldrelationships. An example of this is that not everyone is “best” friendswith every other person they have met in their real-world life. Thereare varying degrees of friendship/acquaintance in the real-world andthere is a need to represent this in the online/electronic forum,amongst other possible types of relationships between people.

SUMMARY OF THE INVENTION

In one embodiment, the present invention may advantageously provide abenefit and rule configuration environment to obviate or mitigate atleast some of the above-presented disadvantages.

In the current one size fits all world, a system is needed that enablescommunity members to connect with their business connections in a waythat represents their multifaceted life with the plurality of othermembers in the community (both known and unknown to the communitymember) because the members do not want to share the same information,communicate and interact in the same way, nor enable people to networkthrough them in the same way, in view of real-world relationships. Anexample of this is that not everyone is “best” friends with every otherperson they have met in their real-world life. There are varying degreesof friendship/acquaintance in the real-world and there is a need torepresent this in the online/electronic forum, amongst other possibletypes of relationships between people. One method is provided forevolving a defined online existing relationship between a first memberand a second member, the online existing relationship defined by aplurality of existing relationship features for use in managing networkinteraction on a communications network between the first member and thesecond member. The method comprising: receiving a new onlinerelationship having new relationship features such that the new featuresare different from the existing relationship features, the newrelationship features being characteristic of the new relationship;aggregating the existing relationship features and the new relationshipfeatures as aggregate relationship features a combination of theexisting relationship features and the new relationship features inorder to define an aggregate relationship; storing the aggregaterelationship features in a storage as relationship data representing theaggregate relationship defined by the relationship features; andaccessing the relationship data in order to determine whether a selectednetwork interaction from one of the members is permitted in view of atleast one of the corresponding aggregate relationship features of theaggregate relationship, and facilitating the selected networkinteraction between the members when determined as permitted; whereinsaid at least one of the corresponding aggregate relationship featuresof the aggregate relationship is used to define as permitted at leastone of the network interaction type, the network interaction content, orthe network interaction format.

A first aspect of the present invention provided is a method forevolving a defined online existing relationship between a first memberand a second member, the online existing relationship defined by aplurality of existing relationship features for use in managing networkinteraction on a communications network between the first member and thesecond member, the method including receiving a new online relationshiphaving new relationship features such that the new features aredifferent from the existing relationship features, the new relationshipfeatures being characteristic of the new relationship; aggregating theexisting relationship features and the new relationship features asaggregate relationship features a combination of the existingrelationship features and the new relationship features in order todefine an aggregate relationship; storing the aggregate relationshipfeatures in a storage as relationship data representing the aggregaterelationship defined by the relationship features; and accessing therelationship data in order to determine whether a selected networkinteraction from one of the members is permitted in view of at least oneof the corresponding aggregate relationship features of the aggregaterelationship, and facilitating the selected network interaction betweenthe members when determined as permitted; wherein said at least one ofthe corresponding aggregate relationship features of the aggregaterelationship is used to define as permitted at least one of the networkinteraction type, the network interaction content, or the networkinteraction format.

A further aspect provided is a method for evolving a defined onlineexisting relationship pair between a first member and a second member,the online existing relationship pair defined by a first existingrelationship role assigned to the first member having a plurality offirst existing role features for use in managing network interaction ona communications network between the first member and the second member,and a second existing relationship role assigned to the second memberhaving a plurality of second existing role features for use in managingthe network interaction between the first member and the second member,the method including receiving a new online relationship pair having anew first relationship role and a second new relationship role, suchthat the corresponding first new role features and the second new rolefeatures are different from the first existing role features and thesecond existing role features, the first new role features and secondnew role features being characteristic of the new relationship pair;aggregating the first existing role features and the first new rolefeatures as aggregate first role features being a combination of thefirst existing role features and the first new role features in order todefine an aggregate first role; aggregating the second existing rolefeatures and the second new role features as aggregate second rolefeatures being a combination of the second existing role features andthe second new role features in order to define an aggregate secondrole; storing the aggregate first role and the aggregate second rolewith their associated aggregate features in a storage as relationshipdata representing an aggregate relationship pair defined by theaggregate roles and their corresponding aggregate role features; andaccessing the relationship data in order to determine whether a selectednetwork interaction from one of the members is permitted in view of atleast one of the corresponding aggregate role or aggregate role featuresof at least one of the aggregate first role or aggregate second role ofthe aggregate relationship pair, and facilitating the selected networkinteraction between the members when determined as permitted; whereinsaid at least one of the corresponding aggregate role or aggregate rolefeatures of at least one of the aggregate first role or aggregate secondrole of the aggregate relationship pair is used to define as permittedat least one of the network interaction type, the network interactioncontent, or the network interaction format.

A further aspect provided is a method for evolving a defined onlineexisting relationship pair between a first member and a second member,the online existing relationship pair defined by a plurality of existingrelationship features for use in managing network interaction on acommunications network between the first member and the second member,the method including receiving a new online relationship pair havingcorresponding new relationship features different from the existingrelationship features, the new relationship features beingcharacteristic of the new relationship pair; combining the existingrelationship features and the new relationship features to generatecombined relationship features by adding a new feature from the newrelationship features to the existing relationship features, such that aminimum number of the existing relationship features remain as part ofthe combined relationship features; storing the combined relationshipfeatures in a storage as relationship data representing the newrelationship pair for the members defined by the correspondingrespective combined relationship features; and accessing therelationship data in order to determine whether a selected networkinteraction from one of the members is permitted in view of at least oneof the corresponding combined relationship features, and facilitatingthe selected network interaction between the members when determined aspermitted; wherein at least one of the corresponding combinedrelationship features of the new relationship pair is used to define aspermitted at least one of the network interaction type, the networkinteraction content, or the network interaction format.

A further aspect provided is a method for evolving a defined onlineexisting relationship pair between a first member and a second member,the online existing relationship pair defined by a first existingrelationship role assigned to the first member having a plurality offirst existing role features for use in managing network interaction ona communications network between the first member and the second member,and a second existing relationship role assigned to the second memberhaving a plurality of second existing role features for use in managingthe network interaction between the first member and the second member,the method including receiving a new online relationship pair havingcorresponding first new role features and the second new role featuresdifferent from the first existing role features and the second existingrole features, the first new role features and second new role featuresbeing characteristic of the new relationship pair; combining the firstexisting role features and the first new role features to generatecombined first role features by adding a new feature from the first newrole features to the first existing role features, such that a minimumnumber of the existing first role features remain as part of thecombined first role features; combining the second existing rolefeatures and the second new role features to generate combined secondrole features by adding a new feature from the second new role featuresto the second existing role features, such that a minimum number of theexisting second role features remain as part of the combined second rolefeatures; storing the combined role features in a storage asrelationship data representing the new relationship pair for the membersdefined by the corresponding respective combined role features; andaccessing the relationship data in order to determine whether a selectednetwork interaction from one of the members is permitted in view of atleast one of the corresponding combined role features, and facilitatingthe selected network interaction between the members when determined aspermitted; wherein at least one of the corresponding combined rolefeatures of the new relationship pair is used to define as permitted atleast one of the network interaction type, the network interactioncontent, or the network interaction format.

A further aspect provided is a method for defining an onlinerelationship pair between a first member and a second member, therelationship pair including a first relationship role assigned to thefirst member having a plurality of first role features for use inmanaging network interaction on a communications network between thefirst member and the second member, and a second relationship roleassigned to the second member having a plurality of second role featuresfor use in managing the network interaction between the first member andthe second member, the method including assigning the first relationshiprole to the first member such that the first role features arecharacteristic of the first relationship role; assigning the secondrelationship role to the second member such that the second rolefeatures are characteristic of the second relationship role, such thatthe second member must confirm the second relationship role in order forthe first member to be able to use the first relationship role in thenetwork interaction between the first and second members; storing thefirst role and the second role with their associated role features in astorage as relationship data representing the relationship pair; andaccessing the relationship data in order to determine whether a selectednetwork interaction from one of the members is permitted in view of atleast one of the corresponding relationship roles or role features of atleast one of the first role or second role of the relationship pair, andfacilitating the selected network interaction between the members whendetermined as permitted; wherein said at least one of the correspondingrelationship roles or role features of at least one of the first role orsecond role of the relationship pair is used to define as permitted atleast one of the network interaction type, the network interactioncontent, or the network interaction format.

BRIEF DESCRIPTION OF THE DRAWINGS

Exemplary embodiments of the invention will now be described inconjunction with the following drawings, by way of example only, inwhich:

FIG. 1 is a block diagram of a relationship network environment;

FIG. 2 shows a block diagram of an example computing device forimplementing components of the system of FIG. 1;

FIG. 3 shows example interactions between members in the relationshipmanagement system of the system of FIG. 1;

FIG. 4 shows an example claim of the environment of FIG. 1;

FIGS. 5 a,5 b, 5 c show example relationship pairs of the members ofFIG. 1;

FIG. 6 shows example member roles of the members of FIG. 1;

FIG. 7 shows an example relationship gate of the system of FIG. 3;

FIG. 8 shows a relationship matrix used by the relationship gate of FIG.3;

FIG. 9 is a further embodiment of the gate of FIG. 8;

FIG. 10 is an example operation of the gate of FIG. 9;

FIG. 11 is an example of banding of the relationships of FIG. 1;

FIG. 12 a is a further embodiment of the relationships of FIG. 1;

FIG. 12 b is an example modification of the relationship of FIG. 12 a;

FIG. 13 shows an example configuration of the administration system ofFIG. 1; and

FIG. 14 shows an example operation of the administration system of FIG.13.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT(S) RelationshipEnvironment Network 10

Referring to FIG. 1, relationship and security in online social andprofessional networks and communities is provided by a relationshipenvironment network 10. The network 10 provides for members 20 (i.e.registered users) and non-members 24 (i.e. unregistered users) of arelationship administration system 26 to connect/communicate 14 over acommunications network 11 with each other in ways that enhance theirreal world relationship, such that their online accounts (relationshipdata 15, otherwise known as a configured relationship matrix 15 for theplurality of members 20 and their optionally assigned relationship roles12 a,b) share information electronically and the members/non-members 20,24 interact with each other electronically in accordance with a definedconnection/shared relationship (e.g. relationship pair 12) defined andadministered by the relationship administration system 26. It isrecognised that both members 20 and non-members 24 will hereafter bereferred to generically as members 20 for the sake of simplicity, suchthat members 20 can be of a type registered or unregistered (i.e.non-members). The administration system 26 provides for a plurality ofdefined relationship pairs 12 assigned to selected pairs of members 20to adapt and change over time through amendment in the one or morerelationship roles 12 a,b (or to their commonly assigned relationshipfeatures 18 that are not assigned to any particular role 12 a,b)assigned to the members 20 for representing any changes in theprofessional and/or personal relationship(s) between the members 20 witheach other over time, as facilitated by relationship pair aggregationfurther described below.

It is also recognised that the term member 20 can be assigned to asingle user and/or a group (e.g. two or more users) by theadministration system 26, such that any individual of the group can usethe group member 20 as a conduit to electronically interact with othergroup and/or individual members 20 via the network 11. For example, agroup member 20 can be a number of individual doctors working togetherin the same clinic and an individual member 20 can be a salesrepresentative connecting with and making appointments with the groupmember 20 as a customer of the sales representative (e.g. for sellingmedical supplies for the group individuals as a whole). It would be upto the individuals of the group member 20 to arrange amongst themselveswho would be meeting the sales representative at the arranged time/placeof the appointment, as the sales representative would not be concernedwith whom of the individuals of the group member 20 attend theappointment—just that at least one of the group individuals would beavailable and make able to make/relay decisions concerning buying ofmedical supplies.

The administration system 26 could consider the group member 20 as adistinct member 20 of the relationship environment 10, realizing thatany of the individuals of the group member 20 would have the samecapabilities/features/privileges 18 and can use the group member 20account 15 to interact 14 with other members 20. Alternatively, theadministration system 26 could consider the group member 20 as adistinct member 20 of the relationship environment 10, realizing thatcertain individuals of the group member 20 would have slightly differingdefined capabilities/features/privileges/restrictions 18 (e.g. definedindividuals when signed on as the group member 20 would only be able toview 14 appointments but not to confirm 14 them) when using the groupmember 20 account 15 to interact with other members 20 associated withthe relationship administration system 26.

One example application of the network 10 and associated administrationsystem 26 is for the healthcare industry, which can be characterized ashaving a particularly fragmented with a workforce—from physicians 20 tonurses 20 to practice administrators 20—that are extremely busy in theirday to day activities. Day to day work in industry can also be highlyirregular and unpredictable, and with so many different parts working inisolation there are limited opportunities for people to be exposed toone another. All of this makes it very difficult for industryprofessionals 20 to get in touch 14 with who they want when they needto, to stay in touch 14 with colleagues 20 and co-workers 20 withinand/or between different industries, and to coordinate productiveinteractions 14 with each other. Accordingly, the ability to coordinate14 meaningful and expected online relationships 12 between members 20,in particular the evolution of relationships between members 20 in aflexible and transparent manner is desirable, as further discussedbelow.

The relationship administration system 26 can be a web-basedservice/application, accessible by browser applications of the members20, and can provide a medium for the community of members 20 for people(in healthcare and other industries) to electronically (i.e. online)find 14 and connect 14 with peers and/or non-peers, electronicallycommunicate 14 and exchange ideas between members 20, and electronicallycoordinate interactions 14 (both online and in person, for example)between members 20; so that community members 20 can develop businessnetworks (for example in conjunction with different types offriendships), build knowledge, and/or engage in purposeful productiverelationships 12 outside of their immediate business environment. It isrecognised that the electronic communications/connections 14 between themembers 20 are conducted in the framework of the defined role pairs 12,for example, and the associated features/capabilities 18, as coordinatedby the administration system 26 further discussed below.

Customer-Vendor Example

Referring to FIGS. 1 and 4, an example of the role pair 12 is Vendors(role 12 a) who use the system 26 to have access to customerrelationship management tools 30 that let them, as companies or asindividual representatives with companies, reach out and connect 14directly to target their Customers (role 12 b) for their proffered goodsand services. The management tools 30 provide the members 20 withdifferent types of connection 14 options with one another over thenetwork 11. The system 26 provides features that support the vendor 20and the customer 20 in building new relationships 12, inenhancing/evolving existing relationships 12, and in enabling electroniccommunication, coordination, and value exchanges 14 between the assignedroles 12 a,b of the role pair 12.

In economics, economic output can be divided into goods and services.When an economic activity yields a valuable or useful thing, it can beknown as production output of the totality of products (e.g. goods orservices) in an economy that the vendor 20 makes available 14 for use bythe customers 20. Products as goods can range from a simple safety pin,food, clothing, computer components to complex aircraft. Products asservices are the performance of any duties or work for another (e.g.helpful or professional activity) and can be used to define intangiblespecialized economic activities such as but not limited to: providingaccess to specific information; web services; transport; banking; legaladvice; accounting advice; management consultant advice; and medicalservices. The vendor 20 providing the products can be abusinessperson/individual engaged in wholesale/retail trade, anorganization, an administration, and/or a business that sells,administers, maintains, charges for or otherwise makes availableproduct(s) that are desirable by the customers 20. Accordingly, thevendor 20 can be one person, or an association of persons, for thepurpose of carrying on some enterprise or business; a corporation; afirm; etc. Further, it is recognized that the offered 14 (electronicallyand/or in person) products/services can be applied to vendor 20activities not related to specific product(s), for example activitiessuch as customer service, community activities, and/or sponsorships.These general activities of the vendor 20 are also considered as part ofthe definition of vendor 20 products.

It will be understood that for the purposes hereof, the customer 20 maybe any user (i.e. first hand product experience) of vendor 20 products(e.g. goods and/or services). For example, the customer 20 may be anindividual who purchases vendor 20 goods and/or services for personaluse, and not for resale or for use in the production of other goodsand/or services for resale. Or the customer 20 may be a businesspurchasing vendor 20 goods and/or services for use in its business,i.e., for resale or for use in the production of other goods and/orservices for resale. Further, it is recognized that customer 20 may notpurchase the goods and/or services. For example, the customer 20 mayhave acquire the goods and/or services pursuant to a free trial offeredby the vendor 20.

Any business or organization can be called an enterprise, whileconsumers are individuals or households that purchase and use goods andservices generated within the economy. It is recognized that bothenterprises and consumers can be included in the definition of customers20. For example, the definition of B2C (Business-to-Consumer) is used todefine the interaction between a business/vendor 20 (e.g. enterprise)that sells products or provides services to end-user consumers (e.g.customers 20). Further, for example, Business-to-Business (B2B) can beused to represent for relations between enterprises (e.g. between abusiness vendor 20 and a business customer 20), contrary to relationsbetween enterprises and other groups (e.g. customers, publicadministration). The term B2B can be used to define marketing activitiesas well as electronic communication relations between enterprises. Forexample, B2B-Marketing can be used to describe all products and servicesused by enterprises. B2B marketing can be considered more complex thanB2C marketing because on the buyer's side, there can be more than oneperson involved in a B2B sale/purchase, the buying center.

Accordingly, it is recognized that the customer 20 can be a privateindividual desiring information/purchase (e.g. B2C) of the vendor 20products or can be a person, or an association of persons, for thepurpose of carrying on some enterprise or business (e.g. a corporation,a firm, etc.) that desires infonnation/purchase (e.g. B2B) of the vendor20 products. It is recognized that the customer 20 can communicate 14with the vendor 20 as a potential purchaser (i.e. window shopping) or asan intended purchaser of the vendor's 20 products, as desired.

Relationship Matrix 15

When two or more members 20 are engaged in one or more relationshippairs 12 (active and/or passive), these members 20 interact 14 with eachother on the administration system 26 (via the network 11) in accordancewith their relationship pair(s) 12 and their respective optional roles12 a,b the members 20 have in those relationship pair(s) 12. It isrecognised that between any pair of members 20, a plurality of distincttypes of relationship pairings 12 can be assigned to them, whichfacilitates the evolution of their overall online relationship with oneanother. For example, any two members 20 can first start off with beingthe role of associates 12 a,b in an associate based relationship pair 12(having associate features/capabilities 18 a,b for coordination of thevarious connections/actions 14 enabled by the associate basedrelationship pair 12. At a later date, the two members 20 then add (e.g.aggregate) being the role of customer-vendor 12 a,b in a customer-vendorbased relationship pair 12 having customer or vendor basedfeatures/capabilities 18 a,b for coordination of the variousconnections/actions 14 enabled by the customer-vendor based relationshippair 12. In other words, the members 20 now have a general relationshipwith one another that is a combination of associate/customer 12 a orassociate/vendor 12 b with one another and therefore all of thefeatures/capabilities 18 a,b assigned to each member 20 is a combinationof associate/customer 18 a or associate/vendor 18 b, as furtherdescribed below with respect to relationship banding and relationshipaggregating. The relationship matrix 15 is used as a memoryconstruct/database (e.g. table, chart, etc.) for defining/storing all ofthe features/capabilities 18 a,b, roles 12 a,b, and/or all the possibleinteractions 14 between members 20 over the network 11.

It is also recognised that as an alternative embodiment the definedonline existing relationship 12 between a first member 20 and a secondmember 20 can be defined by a plurality of existing relationshipfeatures 18 for use in managing network interaction 14 on thecommunications network 11 between the first member 20 and the secondmember 20. The relationship features 18 are characteristic of therelationship 12, such that at least one of the correspondingrelationship features 18 of the relationship 12 is used to define aspermitted at least one of the network interaction 14 type, the networkinteraction content, or the network interaction format. It is recognisedthat the relationship features 18 can be between the first member 20 andthe second member 20 (i.e. each of the members 20 do not have a definedrelationship role 12 a,b, in the relationship 12). Or, as furtherdiscussed above, it is recognised that a first portion of therelationship features 18 a characterizes the first relationship role 12a and a second portion of the relationship features 18 b characterizesthe second relationship role 12 b of the relationship pair 12, such thatthe first relationship role 12 a and the second relationship role 12 bare part of the relationship defined as the relationship pair 12 betweenthe first and second members 20. In other words, the aggregaterelationship pair 12, described above by example only, can beadministered by the administration system 26 as a role-less relationship12, such that the relationship features 18 are shared between themembers 20 for managing their inter-member 20 interactions 14, or can beadministered as a roled 12 a,b relationship pair 12, such that each ofthe roles 12 a,b have characteristic role features 18 a,b.

Referring to FIG. 8, any possible interaction 14 that can occur betweentwo members 20 can be defined and therefore enabled/disabled in therelationship matrix 15 via the respective features 18 and the actualimplementation of the interaction 14 is assessed (through reference tothe matrix 15) and either accepted or declined by the Relationship Gate150. The relationship matrix 15 is therefore available (locally orremotely over the network 11) to the Relationship Gate 150, to maintainan understanding of the roles 12 a,b inside of the assigned relationshippairs 12 in affect (e.g. active and/or passive) at any point in timebetween members 20

The feature or capabilities 18 a,b available between members 20 caninclude such as but not limited to: information visibility/sharing 14(via profiles, searches, contact records, etc.); notifications andupdates 14; communications 14; Events Coordination 14; Interactions 14Online and Coordination 14 of Interactions Offline; Preferences for thefeatures/capabilities 18 a,b (i.e. limited member 20 specificcustomization of the general features/capabilities 18 a,b availableunder the role(s) 12 a,b); and Relationship views 14.

Further, it is recognised that the matrix 15 is used by the relationshipgate 150 to determine whether or not an action 14 initiated by themember 20 with respect to another member 20 (e.g. send a meeting requestfor sales call) will be completed as an allowable RelationshipInteraction 14 (as defined by the features/capabilities 18, 18 a,b,shared or distributed in defined roles 12 a,b), or whether the action 14is halted because it cannot occur (i.e. the desired action 14 is notcompatible with one or both of the feature/capability sets 18, 18 a,b ofthe member(s) 20.

Further, it is recognised that the administration system 26 can providefeedback communication to the requesting member 20 if the action 14resulted in no Interaction (e.g. not allowed). Also, it is recognisedthat the administration system 26 can provide feedback communication tothe requesting member 20 if the action 14 resulted in Interaction (e.g.allowed). Also, it is recognised that the administration system 26 canprovide feedback communication/notification to the intended recipientmember 20 of the action 14 if it resulted in no Interaction (e.g. notallowed). Also, it is recognised that the administration system 26 canprovide feedback communication/notification to the intended recipientmember 20 of the action 14 if it resulted in Interaction (e.g. allowed).

Referring again to FIG. 8, thecapabilities/features/privileges/restrictions 18 a,b (hereafterreferable as features 18 for the sake of simplicity) are grouped asassociated/assigned to the respective individual relationship role 12a,b, for example. For example, a first role type RT1 would have aset/group of assigned features F1,F2,F3,F4,F5,etc. and a second roletype RT2 would have a set/group of assigned features F1,F3,F4,F6,F7,etc.It is recognised that the sets/groups of assigned features 18 can havesome individual features 18 in common (e.g. overlapping sets/groups offeatures 18), however each set/group of features 18 as a whole is uniquein feature 18 content to the respective role type 12 a that they areassigned. In this manner, the administration system 26 can facilitatethat a first role type RT1 has a unique first set of assigned features18 and therefore cannot be confused with a second role type RT2 having aunique second set of assigned features 18, such that the first andsecond set of features 18 are not identical. For example, the role type12 a of a Colleague would have different set of features 18 than that ofa Vendor, otherwise a Colleague could be confused for a Vendor duringinteractions 14 over the network 11 as defined by the particular rolefeatures 18 set that is unique to the particular role type 12 a.

It is also recognised that some features 18 can be superseded by otherfeatures 18, either in whole or in part (e.g. to take the place of suchas replace or to augment so as to make an already assigned feature 18greater/lesser in size, extent, or influence), during aggregation ofrelationship pairs 12 and their corresponding roles 12 a,b and features18 a,b, as further described below with respect to aggregaterelationship pairs 6 (see FIG. 9).

Interactions/Connections/Communications 14

Referring again to FIG. 1, members 20 via the administration system 26can connect 14 with each other in ways that represent their real worldtrusted relationships, including nonmember 20 interactions. It isrecognized that the following discussed member 20 interactions 14 (asfacilitated/defined through the features/capabilities 18 a,b that areshared between members of the relationship pair 12 and/or are associatedwith the role types 12 a,b of the relationship pair 12) is for exemplarypurposes only, recognizing that nonmembers 20 can and will have at leastsome of the features/capabilities 18 a,b that are appropriate to theirbase relationship profile 12 a (e.g. public) recognized by the system26.

Referring to FIGS. 1 and 6, the types of relationships (i.e. role 12 a,bof the defined role pair 12) that member 1 (M1) is in with other members(Mn), and the administration system 26 connection relationships that aM1 has with a specific member (M2), will impact: the information M1 canenter 14 into the relationship data 15 about themselves; the informationM1 is able to share 14 about themselves, and who they're able to shareit with; the features/capabilities 18 a member 20 is able to use intheir defined role(s) 12 a,b; the features/capabilities 18 M1 is able touse when interacting with Mn; the ability for M1 to join a Group; thetypes of requests/responses 14 that the member M1 can have over thenetwork 11; and/or the results 14 of any searches member M1 executes 14.Further, the relationships that a person may be dependent on factorssuch as: the role pair 12 assigned to the member 20; service package(s)purchased or otherwise acquired 18 by the member 20 as facilitated bythe system 26; and organization type and relationship of theorganization with the system 26. For example, in FIG. 6 member M1 (viatheir defined two role pairs 12 of customer-vendor andcolleague-colleague) can communicate 14 (as enabled/defined throughtheir various features/capabilities 18 as share and/or as assigned 18a,b to respective roles 12 a,b) with member M2 being both a fellowcolleague 12 a and a respective customer 12 a of member M1 (being acolleague 12 a and vendor 12 b). For example, member M1 and member M2can interact 14 with each other as colleagues 12 a by sharing 14 theirin-office calendars (e.g. showing both personal and business activities)as well as placing 14 and accepting 14 orders respectively forparticular beauty products (i.e. member M1 is a part-time vendor of skincreams and candles).

Member M1 can also communicate 14 with other vendors 12 b (defined bythe system 26) of the members Mn (for example other part-time vendors ofskin creams) to find out whether their customers may be interested intheir products (i.e. candles) and to make an introduction/referral 14 tothe member Mn customers 12 a. This is an example where member M1 has anactive relationship role 12 of customer-vendor and colleague-colleaguewith member M2 and member M2 has passive relationship roles 12 a,b ofvendor-vendor with other members Mn. It is recognised that the system 26s (and enforce via the relationship gate 150 see FIG. 7) the variouscapabilities/features 18 b of the vendors 12 b differently for theabove-described role pair customer-vendor 12 and vendor-vendor 12. Forexample, member M2 could offer 14 their products for sale to member M1with the ability to provide 14 order forms and invoicing. However,member M2 could not do these same interactions 14 with member Mn, rathermember M2 could only perform with member Mn initial contact 14 andrequest 14 introductions to the customers 12 a of the member Mn. On theother hand, members M2 and Mn could decide to enter into customer-vendorrelationships 12 and then member M2 would gain the additional vendorfeatures/capabilities 18 b commensurate with members Mn being theircustomer 12 a.

It is recognised that the content (e.g. text, image, video, enclosures,message type (email, telephone, text message, etc.), message enclosures,content size/amount/length) and/or format (e.g. form of the content suchas colour, font style, message priority, etc.) of the interactions 14can be defined and their generation by the member 20 coordinated by theassociated features/capabilities 18 (e.g. of the role 12 a,b) that themember 20 is using/operating under on the administration system 26 withselected (active and/or passive) other members 20. It is also recognisedthat the content and/or form of the interactions 14 can be defined usinga combination of different roles 12 a,b and/or their associated features18 a,b in view of aggregation of relationship pairs 12, furtherdescribed below.

In general, when a member (M1) initially connects 14 with another member(M2) via the system 26, M1 can choose the type or types of relationships(e.g. the role pair(s) 12) they are connecting to M2 in. Theserelationship role types can include defined role pairs 12 such as butnot limited to:

Business Relationship Communi- Information Interac- Exchange ManagementRelationship Trust level cations 14 Sharing 14 tions 14 Info 14Capabilities 14 Blocked None None None None None None Public (default)Minimum Minimum Minimum None None None Associate to Low Low Minimum NoneNone None Associate Colleague to High High High High Low Low ColleagueCustomer to Medium Medium Medium High High High Vendor/Vendor toCustomer Student to Medium Medium Medium High None Low Teacher/ Teacherto Student Co-Worker to Medium Medium Medium Medium Medium Med Co-Worker

A number of interactions 14 are impacted by relationshipsfeatures/capabilities 18 of the defined role pair(s) 12 between themembers 20, including for example with respect to booking ofappointments/meetings and the contents/substance of the meetings:

-   -   Ability to input 14 available Time for appointments/meetings as        visible on their online profile 9;    -   Available Time Viewing 14 and Booking 14 for        appointments/meetings as visible on their online profile 9;    -   Sample requests 14 as visible on their online profile 9;    -   Product input and display 14 as visible on their online profile        9 or otherwise sent in communications 14 to their member of the        role pair 12;    -   Territory Management 14;    -   Call Management 14;    -   Call Mapping 14;    -   Auto Call Booking 14; and/or    -   Auto Rebooking 14 of Calls.

Example Interaction 14—Available Appointment Time

Referring to FIG. 1, the AVAILABLE TIME PROCESS allows members 20 whoare connected with each in a VENDOR (i.e. role 12 b) and CUSTOMER (i.e.role 12 a) relationship (i.e. role pair 12) to coordinate theirinteractions 14 so as to facilitate sales calls and meetings that aremore predictable and productive than the current prior art systems. Theprocess enables CUSTOMERS to identify 14 when they have AVAILABLE TIME(either MEETINGS or FLEX CALLS) for VENDORS to visit.

For MEETINGS, the CUSTOMER simply sets up 14 when he wants a VENDOR tocome (e.g. 10 to 10:15 am on Wednesday or 12:30 to 1:30 pm for lunch onThursday.) FLEX CALLS are periods of time that the CUSTOMER hasindicated they will accept a number of drop-in calls (e.g. between 1 pmand 3 pm on Fridays they would accept up to three FLEX CALLS.), asvisible on their online profile 9.

Only members 20 who are connected to a CUSTOMER as a VENDOR can see 14AVAILABLE MEETINGS and/or AVAILABLE FLEX CALLS as visible on theironline profile 9. VENDORS who want to BOOK 14 any OPEN MEETINGS or FLEXCALLS will do so on a first come first serve basis, and in accordancewith any preferences designated by the CUSTOMER as visible on theironline profile 9.

Only one VENDOR may be able to BOOK 14 a single MEETING. Once booked,the AVAILABLE MEETING is BOOKED and may be not visible to other VENDORSfor booking. (Note that a VENDOR or CUSTOMER can CANCEL the meeting,which could reopen the AVAILABLE MEETING to be booked by a differentVENDOR.

Multiple VENDORS can book 14 calls during an AVAILABLE FLEX CALL periodas visible on the CUSTOMER'S online profile 9. The number is limited bythe maximum specified by the CUSTOMER. A FLEX CALL that has been BOOKEDby a VENDOR is a period when they will be expected to drop in to see theCUSTOMER. The system 26 can divide the FLEX CALL period into a number ofset length (and overlapping, if needed) windows. VENDORS who book a FLEXCALL book a specific window, and this distributes the bookings andreduced situations where multiple VENDORS call on a CUSTOMER at the sametime.

The specific time within the AVAILABLE FLEX CALL TIME when the call isto be made is up to the VENDOR. This enables them to choose 14 a timethat works best with their schedule, but also provides flexibility tothe CUSTOMER who has no obligation to maintain an exact meeting time, asinput and then made visible on their online profile 9. Also, the actualdiscussion produced with a FLEX CALL has no set length, and will besomething that works for the VENDOR and the CUSTOMER.

Only system 26 USER TYPES that are in the CUSTOMER class of user typescan create 14 AVAILABLE TIME. Further, only system 26 Users who are aVENDOR CONTACT (i.e. part of the role pair(s) 12 defined between theVENDOR and CUSTOMERS) of these CUSTOMERs can view 14 the AVAILABLE TIMEas visible on the CUSTOMER online profile 9 to book it.

A VENDOR can view 14 a CUSTOMER's calendar on their online profile 9 tofind and BOOK any OPEN (not booked) AVAILABLE FLEX CALL WINDOWS. EachFLEX CALL WINDOW will have a start time and an end time (usually 60minutes apart.)

Only the VENDOR or a CUSTOMER can see and book 14 the AVAILABLE FLEXCALLS on the online profile 9 for the CUSTOMER, as defined and enabledvia their defined role pair 12. To other member types (such ascolleagues, co-workers, etc) the time where an AVAILABLE FLEX CALL canappear 14 on the member's online profile 9 to be BUSY time, whether thecall is BOOKED or OPEN. (This is because the CUSTOMER is saying thistime is booked for my VENDORS, and is therefore expected to be booked.).Accordingly, it is recognized that the online visible profile 9 of anyparticular member 20 to any other member 20 is influenced by the rolepair(s) 12 defined between the respective members 20.

Once a FLEX CALL WINDOW maximum booking number (BWmax) is reached, thatwindow is considered FULL and is not viewable by VENDORS other thanthose that have booked it. For both AVAILABLE MEETINGS and for AVAILABLEFLEX CALLS, the system 26 can permit the CUSTOMER to set PREFERENCES 18for the calls. These PREFERENCES 18 can take the form of:

-   -   Capability to set PREFERRED VENDORS, PREFERRED VENDOR        ORGANIZATIONS, PREFERRED PRODUCT INTERESTS, etc;    -   Frequency that any one VENDOR can BOOK an AVAILABLE MEETING;    -   Frequency that any one PREFERRED VENDOR can BOOK an AVAILABLE        MEETING;    -   Frequency that any one VENDOR can BOOK an FLEX CALL;    -   Frequency that any one PREFERRED VENDOR can BOOK an FLEX CALL;    -   Frequency that any one VENDOR ORGANIZATION can BOOK an AVAILABLE        MEETING;    -   Frequency that any one PREFERRED VENDOR ORGANIZATION can BOOK an        AVAILABLE MEETING;    -   Frequency that any one VENDOR ORGANIZATION can BOOK an FLEX        CALL;    -   Frequency that any one PREFERRED VENDOR ORGANIZATION can BOOK an        FLEX CALL;    -   Frequency that any one VENDOR that is discussing a specific        PRODUCT can call; and/or    -   Some AVAILABLE TIMES can be designated for specific PRODUCTS.        (This can be put in the notes, but the TRApp can also support        this by confirming the product type of the VENDOR.

The system 26 can also facilitate the capability to support multiCUSTOMER calls, and allowing multiple VENDORS to book 14 the same FLEXCALL PERIOD. This would be an event situation. CUSTOMERS can alsocustomize the FLEX CALLS to have FLEX CALL WINDOWS of any length. (e.g.60 minutes in length, except when the entire AVAILABLE FLEX CALLDURATION is 30 minutes when the window can also be only 30 minutes.

Relationships Defined Using Relationship Pairs 12

Referring to FIGS. 1 and 3, control and transparency of all connectionrelationships 12 in the networked environment 10 promotes member 20confidence in interactions 14. Members 20 know who they're connecting 14to, how they're connecting 14 to them, how they're being seen 14 byother members 20 they're connected to, and exactly what it means to beconnected 14 to another member 20 in a specific relationship pair 12.

Further, members 20 have control of their relationships 12, just likethey have in real life. It's not a one size fits all world and, inbusiness, people have different relationships 12. the administrationsystem 26 provides for this, for example through paired relationshiproles 12 a,b, letting members 20 decide what relationship role 12 a,b ofa paired relationship 12 they want to have with another member 20. Thepaired relationship roles 12 a,b (and optional directional relationships12, further described below) can provide that, when a member 20 engages14 in an online relationship 12 with another member 20, they know therole 12 a,b they play in the relationship and the corresponding role 12b,a the connected (of the relationship pair 12) member 20 plays. If apair of members 20 who are in only one customer-vendor relationship 12,then one of the members 20 must be the vendor role 12 b and one must bethe customer role 12 a. Example, in a colleague-colleague relationshippair 12 or in a customer-vendor relationship pair 12, it's clear to bothsides exactly what role 12 a,b each member 20 is playing. For example, Ican't be someone's vendor 20, and not have them be my customer 20.

The relationship environment network 10 provides a social network to themembers 20, by enabling members 20 to connect to each other in ways thatrepresent their real world business relationships using definedrelationship pair(s) 12, including within the pairs 12 example roles 12a,b such as but not limited to: as an associate; as a colleague; as aco-worker; as a customer; as a vendor; etc. Selected roles 12 a,b arecompatible with other selected roles 12 a,b and other selected roles 12a,b are not compatible with certain roles 12 a,b, as further describedbelow (for example, a role 12 a of vendor may not be compatible with thefeatures/capabilities 18 of a role type 12 b of colleague, while a role12 a of vendor would be compatible with the features/capabilities 18 ofa role type 12 b of customer). It is recognised that each of theassociated roles 12 a,b of the role pair 12 includes a pluralityfeatures/capabilities 18 that are defined by the administration system26, as further discussed below. Once connected via the system 26,members 20 users of the administration system 26 communicate, shareinformation, and/or coordinate interactions via communications 14 witheach other in accordance with their professional and/or personrelationship defined by their role(s) 12 a,b with each other in the rolepair(s)/pairing(s) 12. It is recognized that the communications 14 canconsist of messages (e.g. SMS messages, texting, emails, phone calls,etc.) sent to one another, as well as viewing the online profiles 9(e.g. system 26 Web page showing the profile of the member 20 with username, interests, other member 20 connections, hobbies, etc.) of themembers 20.

Some relationships require both members 20 to be in the same role 12 a,such as in a Colleague to Colleague relationship 12. Otherrelationships, such as Customer to Vendor relationships 12, require eachuser to have a different role 12 a,b.

Referring to FIGS. 5 a,b,c, in any relationship pairing 12, there can betwo relationship roles 12 a,b that may be of the same or different roletypes. In FIG. 5 a M1 is the colleague 12 a and M2 is also the colleague12 a, such that both members 20 M1 to M2 want to be Colleagues so bothusers must play the role of a Colleague 12 a in this Colleague toColleague relationship 12. In FIG. 5 b M1 is the customer 12 a and M2 isthe vendor 12 b, such that the two members 20 M1 and M2 want to be in aCustomer to Vendor relationship 12 where M1 plays the Customer role 12 aand M2 plays the Vendor role 12 b. In FIG. 5 c M1 is the customer 12 aand M2 is the vendor 12 b for one relationship pair 12 and M1 is thevendor 12 b and M2 is the customer 12 a for another relationship pair12′ that they have, such that the same M1 and M2 members 20 can alsohave a second Customer to Vendor relationship 12′ where M2 plays theCustomer role 12 a and M1 plays the Vendor role 12 b.

A relationship role 12 a,b is the specific capacity a member 20 takeswhen acting in a system 26 supported relationship 12 with another member20 who has a specific counter/associated role 12 a,b to thatrelationship pairing 12. It is recognised that the capabilities andfeatures 18 between two paired roles 12 a,b may not be the same. Forexample, in a Customer to Vendor relationship 12, one user must alwaysbe the role 12 a of Customer 20 while the other user must always be therole 12 b of Vendor 20, since the customer 20 is the one who asksquestions about and purchases items from the vendor 20, while the vendor20 is the one that provides answers about products and facilitates saleof their products. The administration system 26 would define (via thematrix 15) and can assign of the allowable features 18 a,b specific tothe assigned role 12 a,b of the role pair 12. In other words, forexample, the customer 20 would not have (i.e. the matrix 15 would notenable these features 18 b for the customer role 12 a) the vendor 12 btype features 18 b of offering 14 products for sale and invoicing 14 forsame over the network 11 with the vendor 20 (since that is what a vendor20 does), while at the same time the vendor 20 would not have (i.e. thematrix 15 would not enable these features 18 a for the vendor roles 12b) the customer 12 a type features 18 a of requesting 14 productinformation and paying 14 invoices for purchased products over thenetwork 11 with the customer 20 (since that is what a customer 20 does).Accordingly, in this case, it is clear that a particular member 20 canonly be the customer role 12 a with corresponding features 18 a whenpaired to the particular member 20 who is the corresponding vendor 12 brole with corresponding features 18 b, for the relationship pairing 12of customer-vendor for the paired members 20. It is also recognised thatthe features 18 of a selected relationship pair 12 can be shared betweenthe members 20 of that relationship pair 12 in a role-less relationshippair 12.

For example, referring to FIG. 3, the system 26 provides a plurality ofpredefined role pairs 12 for selection by each of the members 20 (e.g. aplurality of different defined role pairs 12 having respective role 12 aassociated with role 12 b, such that each of the defined role pairs 12have assigned respective different feature/capability sets 18) that canbe assigned to any particular pair of the members 20. Therefore, each ofthe defined role pairs 12 has list of available features/capabilities 18that are associated with the particular role pair 12, for example role12 a of role pair 12 has a list of features/capabilities 18 a that iscompatible with the list of features/capabilities 18 b of the role 12 bof the role pair 12. It is recognized that the features/capabilities 18a may or may not be exactly the same as the features/capabilities 18 b,i.e. may be different for each member 20 of the pair 12 such as forvendor-customers, student-teacher, etc. This is different from the casewhere the roles 12 a are the same/equal such as for colleague tocolleague, friend to friend, member to member. In the case where thefeatures/capabilities 18 a are the same, this could be where therelationship role pair 12 has two equal roles 12 a (e.g. public topublic, friend to friend, colleague to colleague). In the case where thefeatures/capabilities 18 a,b are not the same, this could be where therelationship role pair 12 has two associated dissimilar roles 12 a,b(e.g. vendor to customer, student to teacher), however, it is recognizedthat the dissimilar features/capabilities 18 a,b would be compatiblewith one another as defined by the role pair 12. It is also recognisedthat the features/capabilities 18 a,b assigned to the roles 12 a,b canbe directional, such that there may be more assignedfeatures/capabilities 18 a for the role 12 a as compared to the that thefeatures/capabilities 18 b assigned to the role 12 b of the role pair12, as further described below.

The features/capabilities 18 assigned to the roles 12 are reflected intype of connections 14 that can be initiated (and responded to) by themembers 20 in their relationship role(s) 12, An example of this is wherethe first member 20 having the role 12 a could be a vendor and be ableto send vendor communications 14 listing products/services for sale,while the second member 20 having the paired role 12 b of a customerwould be able to receive 14, view 14, and respond 14 to the originalvendor communications 14 (e.g. order to buy offered products/services),i.e. the members are in a Vendor-Customer role pair 12 relationship, asdefined in the system 26. It is recognized that the customer would notbe able to send vendor communications 14 to the vendor and the vendorwould not be able to place orders 14 to the customer, in this case,unless the members 20 had their relationship role data 15 defining botha Vendorp-Customer role pair 12 and a Customer-Vendor role pair 12between them, such that each member is both a customer and a vendor withrespect to the other member 20 of their defined role pair(s) 12.

It is also recognized that for an active relationship 12 in theadministration system 26, both sides of the relationship pair 12 can becognizant of the assigned roles 12 a,b of their other member 20 of theirmember pair 12, i.e. a vendor knows who their customer is and thecustomer knows who their vendor is and each is knowledgeable of thefeatures/capabilities 18 of the others role 12. In other words, a firstmember 20 cannot hide the fact from a second member 20 that the members20 have defined and dissimilar roles 12 a,b that are compatible with oneanother (e.g. a customer of a vendor knows that they are identified inthe system 26 as the customer of the respective vendor and the vendor ofthe customer knows that they are identified in the system 26 as thevendor of the respective customer. It is also recognized that each ofthe members 20 can have a plurality of different roles 12 a,b (ofrespective role pairs 12) with the same and/or different member(s) 20,such that each of the role pairs 12 (active and/or passive) have aninbound and an outbound role connection (i.e. directional roles 12 a,b)to the other member 20 associated in the role pair 12.

For example, a first member 20 signs onto the system 26 and provides auser role/profile 12 a (e.g. their profession, their specialty, theircountry, hobbies, and any other personal defining information). Thefirst member 20 may also set up with the system 26 certain defined roles12 a,b that may or may not have accepted member pair relationships 12(e.g. the first member 20 can have a vendor role 12 b with aconfirmed/accepted customer role 12 a with a second member 20 thatdefines an active pair relationship 12, and/or the first member 20 canregister with the system 26 as a vendor 12 b of a specificproduct/service and therefore have information 14 available to othermembers 20 as passive pair relationships 12). The system 26 can use theuser role definitions/parameters 18 b as well as any defined roles 12 bas set up by the first member 20 to provide for both active and passiveexchanges of information 14 between the first and second members 20. Forexample, in the case where the first member 10 is a general physicianand the second member 10 is a vendor for office medical supplies, thesystem 26 would use the user role/profile 12 a of general physician andthe defined vendor role 12 b to inform the first member 20 of the secondmember 20 as a potential supplier/vendor 12 b of medical supplies andthe second member 20 of the first member 20 as a potential customer 12 aof their vendor role 12 b. The mappings between potential role pairs 12(i.e. customer 12 a with vendor 12 b) as well as for accepted pairs 12can be monitored/maintained by the relationship matrix 15, as furtherdescribed below.

Therefore, providing members 20 control over the connection types(relationship role pair(s) 12) they have with other members 20 providesthey feel secure in that defined relationship 12. It is recognized thatthe relationship administration system 26 can have one or more defaultrole pairs 12 that can be assigned to nonmembers 20 trying tocommunicate 14 with one or more members/nonmembers 20 via the system 26.For example, each nonmember 20 can be recognized as having a public roleprofile 12 a when trying to communicate via the system 26 with othermembers/nonmembers 20, who will also be associated with a public roleprofile 12 a for facilitating communications 14 via the system 26 withthe non-member 20.

Example definitions of the various roles 12 a,b available in theplurality of relationship pairs 12 is as follows. Associate is a personwho shares actively in anything as a business, enterprise, orundertaking as a partner or fellow worker. Colleague is a fellow memberof a profession, staff, or academic faculty. Friend is a person attachedto another by feelings of affection or personal regard and is a personwho gives assistance as a patron/supporter. Teacher is a person whoteaches or instructs, as a profession as an instructor. Coworker is afellow worker. Vendor is a person or agency that sellsproducts/services. Customer is a person who purchases goods or servicesfrom another as a buyer/patron. Student is a person formally engaged inlearning, especially one enrolled in a school or college as a pupil.Manager is a person who has control or direction of an institution,business, etc., or of a part, division, or phase of it. “Co” (e.g.co-manager, co-vender, etc.) is a fellow person with potentially thesame business/personal duties as another person. Delegate is a persondesignated to act for or represent another or others, for example as adeputy/representative. Patient is a person who is under medical care ortreatment. Provider is a person or thing that provides a service (e.g.healthcare related) to another person or thing.

Directional Relationship roles 12 a,b

It is recognised that the relationship pairings 12 can benon-directional and/or directional relationship roles 12 a,b andassociated non-directional and/or directional relationshipfeatures/capabilities 18 a,b. For example, if two members 20 are in acustomer-vendor relationship pair 12, it is possible for those members20 to engage in another customer-vendor relationship pair 20. In thefirst relationship pair 12, member M1 may be the vendor and member M2may be the customer, while in the second relationship pair, member M1may be the customer, and member M2 may be the vendor. In this case, M1would only be enabled for the first relationship pair 12 for directionaloutgoing vendor interactions 14 (i.e. to customer) and incoming vendorinteractions 14 (e.g. from customer) in terms of the availablefeatures/capabilities 18 b for a vendor 12 b. As well, M1 would only beenabled for the second relationship pair 12 for directional outgoingcustomer interactions 14 (i.e. to vendor) and incoming customerinteractions 14 (e.g. from vendor) in terms of the availablefeatures/capabilities 18 b for a customer 12 a, for example. Further, M2would only be enabled for the first relationship pair 12 for directionaloutgoing customer interactions 14 (i.e. to vendor) and incoming customerinteractions 14 (e.g. from vendor) in teens of the availablefeatures/capabilities 18 b for a customer 12 a. As well, M2 would onlybe enabled for the second relationship pair 12 for directional outgoingvendor interactions 14 (i.e. to customer) and incoming vendorinteractions 14 (e.g. from customer) in terms of the availablefeatures/capabilities 18 b for a vendor 12 b, for example.

Another way to think about it is that relationship pairs can beoptionally directional, from one role 12 a,b to the other. Therefore,the capabilities and features 18 a,b between two members 20 may not bethe same, because the direction of the relationship pair 12 matters. Forexample, in a Customer to Vendor relationship pair 12, one member 20must always be the Customer role 12 a while the other member 20 mustalways be the Vendor role 12 b. In this case, there is oneCustomer-Vendor relationship pair 12, but two separate RelationshipRoles 12 a,b in that relationship pair 12: one Customer and one Vendor.This is talking to the fact that two people 20 can have tocustomer-vendor relationships 12, one in each direction, but that theycan have different features/capabilities 18 a,b because the users 20 maycustomize how the accept/broadcast those features 18 a,b.

Therefore, it is recognised that each relationship pair 12 providescapabilities 18 a,b to the members 20. The relationship matrix 15 is incontact with the Relationship Gate 150, to maintain an understanding ofthe roles 12 a,b and relationship pair(s) 12 in affect at any point intime between members 20.

Active/Passive Relationship Pairs 12

Each relationship between a pair of members 20 (e.g. member with member,member with non-member, or non-member with non-member) can consist ofone or more relationship pairs 12 (e.g. a first role 12 a of the pair 12is assigned to one member 20 of the member pair and anassociated/complimentary second role 12 b of the pair 12 is assigned tothe other member 20 of the member pair). It is recognized that there canbe both passive (one of the roles 12 a,b of the pair 12 has not beenformally accepted by one of the members 20 of the member pair 12) andactive relationships in the system 26 (i.e. both of the roles 12 a,b ofthe pair 12 have been recognized and accepted by each member 20 of themember pair 12—e.g. a first member 20 of the member pair 12 registerswith the administration system 26 in one of the roles 12 a of the pair12 and the second member 20 of the member pair 12 formally accepts arole invitation 14 from the first member 20 for the other role 12 b ofthe pair 12, as defined by the administration system 26).

Referring to FIGS. 1 and 7, there are two types of Relationship pairs12: Activated/Active Relationships 12 and Inherent/Passive Relationships12. Inherent relationships 12 can exist without the member 20 or members20 having to do anything specific to engage or activate the relationship12 between one or more members 20 accessible by the member via theadministration system 26 (e.g. via the relationship gate 150). Forexample, a relationship pair request 14 from a first member 20 does nothave to be received from and accepted by a second member 20, in order toestablish the inherent relationship pairing 12 and (and optionalassociate roles 12 a,b) between two or more members 20. The relationshippair 12 is automatically put in place by the administration system 26when specific member 20 actions 14 occur that would enable the use oftheir inherent optional relationship role(s) 12 a,b and assignedfeatures 18 a,b or as their shared features 18 of the relationship pair12. FIG. 7 shows how the two inherent relationships 12 are always on.

Some inherent relationship pairs 12 include: a) Member (M) to Public (P)(which exists between any member 20 and any non-member 20; b) Member (M)to Member (M) (which exists between every member 20; and c) FamilyHealth Team mate (FHT) to Family Health Team (FHT) mate (which existsbetween all members 20 of a specific family health team;

Further, activated Relationship pairs 12 are started by one of themembers 20 who wants to engage in the selected relationship pair 12. Tostart an active relationship pair 12, one member 20 Initiates aHandshake(request 14 to enter into the relationship pair 12) to aselected other member 20 of the administration system 26. By executing14 the Handshake by the other member 20, the other member 20 activatesthe requested relationship pair 12 and therefore the requesting memberassumes the role 12 a and the accepting member 20 assumes the role 12 bof the relationship pair 12 with the associated features/capabilities 18a,b associated with their roes 12 a,b.

It is recognised that Most relationships can be Activated Relationshippairs 12, including a plurality of relationship pair 12 types such asbut not limited to: Friend (F) to Friend (F); Associate (As) toAssociate (As); Colleague (Co) to Colleague (Co); Coworker (Cw) toCoworker (Cw); Customer (Cu) to Vendor (V)/Vendor (V) to Customer (Cu);Student (St) to Teacher (Te)/Teacher (Te) to Student (St); Report (Re)to Manager (Mg)/Manager (Mg) to Report (Re); Delegate (Dte) to Delegator(Dtr)/Delegator (Dtr) to Delegate (Dte); CoVender to CoVender(CV);CoTeacher to CoTeacher(CT); CoManger to CoManager(CM); and Patient (Pat)to Provider (Pro)/Provider (Pro) to Patient (Pat), as shown in FIG. 7 asexample roles 12 a,b.

Therefore, when two members (assume M1 and M2) are in a relationshippair 12 with each other, there are Passive and/or Active relationshipinteractions 14 that may take place within the features/capabilities 18a,b (optionally associated with the roles 12 a,b) of the relationshippair 12 of the members M1,M2. For example, Active Interactions 14 can betriggered by an action 14 taken by member M1 or M2, such as activeinteractions but not limited to: Vendors request to ‘view availabletime’ and see the available flex calls of their Customers; Vendorsbooking available time for a call, since only vendors can book availabletime; and a member 20 changing their contact information (e.g. mobilephone number), such that this change is then shared with all of hisColleagues. In terms of passive interactions 14, these can happenwithout member M1 or M2 triggering the specific interaction. Examples ofpassive interactions 14 are such as but not limited to: the capabilityfor assuming M1 and M2 are colleagues; and a third member (M3) to seewho M1 is and that they are connected as colleagues to M2.

In an active exchange 14, there are connecting cooperative features 18a,b between the members 20. Every feature 18 a,b can have an entry wayand an exit way. In an active exchange 14, the relationship role 12 a ofthe Initiator 20 must be such that the feature 18 a can ‘Fit’ to allowthe initiation of the exchange 14 (e.g. create and send meetingrequest), and the relationship role 12 b of the Receiver 20 must be suchthat the cooperative feature 18 b will Fit the receiving end (e.g.receive and accept/decline meeting request) of the exchange 14.

It is recognised that whether or not a relationship pair 12 can exist,is available to start, and/or is maintained, etc, with respect to themembers 20 of the administration system 26 is coordinated theRelationship Gate 150, further described below.

The Relationship Gate 150

Referring to FIGS. 1 and 9, sending of interactions 14 (e.g. messages,emails, or viewing, or other network 11 enabled communications) does notalways require that the member 20 be in an active relationship pair 12,as in the case where the profile 9 of the member 20 is being viewed by anon-member 20.

The Relationship Gate 150 is used by the administration system 26 toprovide for allowed interactions 14 (e.g. in type, content and/orformat) between any members 20 over the network 11. The relationshipgate 150 has access to the relationship matrix 15 (see FIG. 8) thatstores all the available roles 12 a,b and/or corresponding features 18a,b to a respective member 20 (e.g. for example in the case of anon-member 24, the administration system 26 can assign a default role(s)12 a,b and corresponding feature(s) 18 a,b). The relationship gate 150can be used to restrict the transmission via the network 11 of anygenerated interactions 14 that do not match with the sender member 20and/or receiver member 20 assigned roles 12 a,b and/or features 18 a,b(shared or not). Alternatively, or in addition to, the relationship gate150 can be used to restrict the generation of any interactions 14 thatdo not match with the sender member 20 and/or receiver member 20assigned roles 12 a,b and/or features 18 a,b (shared or not).

For example, the member 20 may generate a vendor-based communication 14and then try to send the vendor-based communication 14 to a non-customerof the member 20, for which the relationship gate 150 would review theroles 12 a,b and/or features 18 a,b (shared or not) of the non-customermember 20, determine that the vendor-based communication 14 isinappropriate for the non-customer member 20 and then block or otherwiseinform (e.g. using a message that informs the role 12 a,bincompatibility of the non-customer member 20 with a suggestion ofsending an invitation instead to enter into a vendor-customerrelationship role 12 with the member 20) the vendor member 20 of theinability to transmit the vendor-based communication 14. In thissituation, the relationship gate 150 could also modify and/or suggest(to the sending member 20) modifications to the vendor-basedcommunication 14 to include a customer role 12 b invitation for sendingto the non-customer member 20. In an alternative embodiment, therelationship gate 150 could block the member 20 from generating amessage 14 that is not consistent (e.g. in terms of message type,content, and/or format) with any of their current roles 12 a,b and/orfeatures 18 a,b (shared or not). For example, the member 20 may want togenerate a solicitation email for a new product line being sold by thevendor member 20, however the product line and materials associatedtherewith (e.g. invoices, ordering forms, brochures, etc.) may not beenabled in the roles 12 a,b and/or features 18 a,b (shared or not) ofthe member 20 in the matrix 15. The relationship gate 150 could respondto the member 20 to inform the member of the roles12 a,b and/or features18 a,b lacking in their account 9, which needed in order to be able togenerate the desired new product line message 14. For example, maybe themember's account 9 needs to be upgraded for multiple product line vendorstatus before the new product line can be a subject of communications bythe member 20.

Accordingly, the relationship gate 150 is used by the administrationsystem 26 to check whether any relationship pair 12, associated roles 12a,b, and/or features 18 a,b (shared or not) are in place, may beenabled, or are to be disabled, in order to facilitate the interactions14 desired by any of the members 20 with respect to other selectedmembers 20 of the system 26. If, at any time, two members 20 are in arelationship pair 12 where the relationship pair becomes unavailable oreither relationship role 12 a,b becomes unavailable to one of themembers 20, then the relationship pair 12 can become cancelled from thematrix 15. For example, one of the members 20 of the relationship pair20 can leave the administration system 26, thereby cancelling theiraccount 9. In this case, all of the relationship pairs 12 with thismember 20 would be cancelled and all of the corresponding relation roles12 a,b would be deleted or otherwise treated as inactive in the matrixby the administration system 26. It is recognised that the relationshipgate 150 could be used to update the matrix 15 for changes in roles 12a,b, and/or features 18 a,b (shared or not), as desired.

Referring again to FIG. 9, or example, for Member 1 (M1) to be acustomer 12 a and Member 2 (M2) to be a Vendor 12 b: 1. M1 is able to bea Customer 12 a; 2. M2 is able to be a Vendor 12 b; 3. M1 does not haveany Relationship pair 12 Restrictions 18 a preventing them frominitiating (or maintaining) a Relationship pair where they are theCustomer 12 a; 4. M2 does not have any Relationship Restrictions 18 bpreventing them from initiating (or maintaining) a Relationship pairwhere they are the Vendor 12 b; 5. M1 does not have any OrganizationRestrictions 18 a preventing them from being a Customer 12 a; 6. M2 doesnot have any Organization Restrictions 18 b preventing them from being aVendor 12 b; 7. M1 and M2 do not (in a Customer to Vendor relationship)work 18 a,b at the same Organisation; 8. M1 is not in any relationshippairs 12 that would restrict or prevent them from initiating ormaintaining a Customer to Vendor relationship pair and being theCustomer 12 a; 9. M2 is not in any relationship pairs 12 that wouldrestrict or prevent them from initiating or maintaining a Customer toVendor relationship 12 and being the Vendor 12 b, for exampleRelationship count limits 18 a,b fall in here since a member 20 cannotinitiate a new relationship pair 12 of a specific type if he or she hasalready used up all the availability of that relationship pair type 12).

Further to the above, it is recognised that features 18 a,b of aparticular role 12 a,b can contribute to revenue generation and enhancedrelationships possible with differentiated relationship pairs 12 havinguniquely characterizing role(s) 12 a,b and associated features 18 a,b(as compared to other different role(s) 12 a,b, in relationship pairs12), such that the healthcare providers (or other industry specificmembers 20) can comfortably connect with both their colleagues and theirvendors. Members20 may have to pay to be able to be engage in specificrelationship pairs 12 and/or to gain desired features 18 a,b (e.g.feature enhancements) for their selected roles 12 a,b. For example, aservice package that a member 20 purchases from the administrationsystem 26 may restrict/enable 18 a,b not only the types of relationshiproles 12 a,b the member 20 can be, but the number of times 18 a,b themember 20 can engage in a relationship pair 12 where they are playingthat role 12 a,b. For example, the administration system 26 may chargemarketing professionals 20 a marketing charge (e.g. $100/month) to beable to be 18 a,b a Vendor in customer-vendor relationship pair 12.Further, the $100 package may only allow 18 a,b the member 20 to havelimited number (e.g. 50) customer-vendor relationship pairs 12 wherethey are the Vendor 12 a, while an increased value ($200/month) packagemay allow 18 a,b more/additional/increased (e.g. 200) customer-vendorrelationship pairs 12, for example.

Handshake Example

Referring to FIGS. 1, 9, and 10, in Relationship Creation orHandshaking, e.g. for active relationship pairs 12, there is a Sender M1(or Initiator) and a Receiver M2. The Relationship Gate 150 decides,based on matrix data 15 for sender/receiver members 20, whether or not arelationship pair 12 is already in place, may be enabled, or is to bedisabled. There matrix defined factor(s) (e.g. matrix data 15 of therelationships including optional role 12 a,b and/or feature 18 a,b(shared or not) for the members 20) that impact whether a member 20 canor cannot initiate a relationship and play a specific relationship 12with another member 20, such as but not limited to: 1. the Sender M1capability to be in the specific Relationship Role 12 a; 2. the ReceiverM2 capability to be in the specific Relationship Role 12 b; 3. if SenderM1 has any Relationship pair 12 Restrictions 18 a and/or RelationshipEnhancements 18 a (which for example can be provided via paid forservice packages, organization affiliation, member affiliations, etc.);4. if Receiver M2 has any Relationship Restrictions 18 b and/orRelationship Enhancements 18 b; 5. the Type of Organization the SenderM1 works with; 6. the Type of Organization the Receiver M2 works with;7. whether or not the Sender M1 and Receiver M2 work at the sameorganization; 8. whether or not the Sender M1 shares a relationship pair12 with any other member (e.g. M3) that would restrict the sender M1being able to enter into this relationship pair 12; and/or 9. whether ornot the Receiver M2 shares a relationship pair 12 with any other member(e.g. M3) that would restrict the receiver M2 being able to enter intothis relationship pair 12.

Referring again to FIG. 10, assume Member M1 wishes to initiate arelationship pair 12 with Member M2, such that they have not activatedany relationships previously. The Member to Public (P) is always active,but is superseded in this exchange by the Member to Member ‘Port’ 150 a(such that the relationship gate 150 can have a number of ports 150 aopen and/or operable for the members 20 depending upon their roles 12a,b and/or features 18 a,b. The Member to Member (M) Port is engagedbetween any two members 20. Assume the matrix 15 has data 15 that iscompatible with the potential initiation invitations 14 for thepotential relationship pairs 12 displayed in FIG. 10. In reviewing therelationship roles that sender M1 can initiate with M2,•Associate (As)12 a,b is available; Colleague(Co) 12 a,b is available; CoWorker(CW) 12a,b is unavailable with M2 because they are not at the same organisation18 a,b; Vendor (V) 12 a,b is unavailable with anyone; Customer (Cu) 12a,b is available with M2 who can be a Vendor 12 a,b; Teacher (Te) 12 a,bis unavailable with anyone; Student (St) 12 a,b is unavailable with M2because M2 cannot be a Teacher to anyone; Manager (Ma) 12 a,b isunavailable with anyone; and Report (Re) 12 a,b is unavailable with M2because M2 cannot be a Manager to anyone.

Relationship Banding

Referring to FIGS. 1 and 11, the features and capabilities 18 (shared ornot) associated with each relationship pairing 12 has a specific numberof defined features 18 as part of a minimum boundary/band feature set22,23 (e.g. combined) for each of the relationship pair 12 types (i.e.the features 18 in the minimum boundary/band feature set 22,23 mustremain enabled by the members 20 if they are to remain in the acceptedrelationship 12 selected/established between them. For example, therelationship pair 12 type “Associate to Associate” has a minimum bandfeature set 22 of F108 to F115 and the “Colleague to Colleague” has aminimum band feature set 23 of F100, F198,F199,F153 to F155. The members20 in the “Associate to Associate” relationship pair 12 know that eachof the members 20 has these minimum number of features 18 in theirminimum band feature set 22 for the respective relationship pair 12type, in order to maintain transparency and trust about the relationshippair 12 the members 20 created between each other (i.e. representativeof what it means to be in the relationship 12 characterized as associateto associate).

In the event that the relationship 12 between the members 20 evolves toinclude a second enriched relationship pair 12 (e.g. Colleague toColleague), which builds upon the first relationship pair 12 (e.g.associate to associate), the administration system 26 manages thatadditional features of a respective minimum boundary/band feature set 23for the second relationship pair 12 are added to the now aggregaterelationship 6, while providing that the first minimum boundary/bandfeature set 22 is maintained by the members 20 in the aggregaterelationship pair 6 (i.e. characterizing the combination of theassociate to associate and colleague to colleague relationships). Inthis manner, the members 20 in the aggregate relationship pair 6understand that the aggregate relationship pair 6 is characterized by atleast the features 18 contained in both minimum boundary/band featuresets 22,23.

Also in FIG. 9, it is shown that when in just a “member to member”public relationship pair 12, the minimum boundary/band feature set 25 isF001, F007, F011, F014, F015 and F031-F033, such that these features 18are all superseded (i.e. replaced, substituted) when the relationshippair 12 evolves to the associate to associate and the colleague tocolleague. In other words, the relationship features 18 for associate toassociate completely supersede those for the member to memberrelationship pair 12. It is recognised that the banded features 18 canbe optionally part of the individual roles 12 a,b of the relationshippair 12, as desired.

Accordingly, relationships of the same name (e.g. relationship pair 12type), as defined by the administration system 26, always have minimumboundary/band feature sets 22, even when they are being used bydifferent members 20. This minimum number of features 18 enforced in therelationship pair 12 provides for that all members 20 understand what acolleague is, and what a vendor is, and what a customer is, for example.Though there can be some flexibility in relationship pairs 12, meaningthat members 20 can have some control as to how much information (e.g.enabled features 18) they have in a specific relationship pair 12 type,the minimum boundary/band feature sets 22 provide that no one member candeviate too far from those respective minimum features 18 of therelationship pair 12. For example, one member 20 as a colleague role 12a,b cannot have the same features 18 and information sharingcapabilities 18 a,b as another member 20 as a vendor role 12 a,b,otherwise relationship roles 12 a,b would cease to have any meaning inthe context of different relationship pair 12 types having differentfeatures 18 a,b.

One embodiment of the defined roles 12 a,b provides for the banding ofthe features/capabilities 18 a,b, such that progression from one lesserrole to the next greater role between any member pair 12 (e.g. fromfriend to colleague) provides for a minimum number of thefeatures/capabilities 18 a,b of the lesser role 12 a,b to be included asdefault features (e.g. part of the minimum boundary/band feature sets22) for the greater role 12 a,b. This banding provides for members 20 totruly represent their accepted role 12 a,b when interacting with theother members 20 of the member pair 12 using the assigned defined role12 a,b. For example, a member 20 who has accepted another member 20 as afriend cannot simply turn off access 18 to the other member 20 fromtheir contact information (e.g. phone number, email address, homeaddress, etc.) that appropriately represents the friend role 12 a,b. Itis understood that to be an accepted friend, some member information(and any other appropriate features/capabilities 18) cannot berestricted from the other member 20 of the member pair 12 on an ad hocbasis. In other words, turning off or otherwise disabling of features 18from the minimum boundary/band feature set(s) 22 would cause the statedrelationship pair 6,12 to lose the understood (by the members 20) role12 a,b characteristics inherent in the relationship pair 6,12 assignedto the members 20. It is also understood that the evolution of theminimum boundary/band feature sets 22 for aggregate relationship pairs 6can be hierarchical in assignment.

Referring again to FIG. 8, thecapabilities/features/privileges/restrictions 18 are grouped asassociated/assigned to the respective individual relationship role 12a,b. It is recognised that the sets/groups 22,23 of assigned features 18can have some individual features 18 in common (e.g. overlappingsets/groups 22,23 of features 18), however each set/group 22,23 offeatures 18 as a whole is unique in feature 18 content to the respectiverole type 12 a that they are assigned. In this manner, theadministration system 26 can facilitate that a role 12 type has a uniquefirst set 22 of assigned features 18 and therefore cannot be confusedwith a second role 12 type having a unique second set 23 of assignedfeatures 18, such that the first 22 and second set 22 of features 18 arenot identical. For example, the role type 12 a of a Colleague would havedifferent set 23 of features 18 than that of an Associate, as would theaggregate role 8 of associate+colleague (see FIG. 9) would have anaggregate set 22+23 of features 18

It is also recognised that some features 18 can be superseded by otherfeatures 18, either in whole or in part (e.g. to take the place of suchas replace or to augment so as to make an already assigned feature 18greater/lesser in size, extent, or influence), during aggregation ofrelationship pairs 12 and their corresponding roles 12 a,b and featuressets 22,23, as further described below with respect to aggregaterelationship pairs 6 (see FIG. 9).

As an alternative embodiment to relationships 12 and banding, it is alsorecognised that the defined online existing relationship 12 between afirst member 20 and a second member 20 can be defined by a plurality ofexisting relationship features 18 for use in managing networkinteraction 14 on the communications network 11 between the first member20 and the second member 20. The relationship features 18 arecharacteristic of the relationship 12, such that at least one of thecorresponding relationship features 18 of the relationship 12 is used todefine as permitted at least one of the network interaction 14 type, thenetwork interaction content, or the network interaction format. It isrecognised that the relationship features 18 can be between the firstmember 20 and the second member 20 (i.e. each of the members 20 do nothave a defined relationship role 12 a,b, in the relationship 12). Or, asfurther discussed above, it is recognised that a first portion of therelationship features 18 a characterizes the first relationship role 12a and a second portion of the relationship features18 b characterizesthe second relationship role 12 b, such that the first relationship role12 a and the second relationship role 12 b are part of the relationshipdefined as the relationship pair 12 between the first and second members20. In other words, the aggregate relationship pair 12, described aboveby example only, can be administered by the administration system 26 asa role less relationship 12, such that the relationship features 18 areshared between the members 20 for managing their inter-member 20interactions 14.

Relationship Aggregation

Referring to FIGS. 1 and 12 a,b, the relationship pairs 12 and theassociated roles 12 a that are assigned to a respective member 20 by theadministration system 26 can change over time, as the onlinerelationship the member 20 has with other members 20 alsogrows/changes/evolves over time. Flexibility in relationship 12evolution management is facilitated by the ability of the administrationsystem 26 to aggregate relationship pairs 12. Members 20 may not alwayshave the same relationship with each other over time, and therefore theadministration system 26 provides the environment for memberrelationships to alter, grow, and/or diminish in their relationshipcharacteristics (e.g. relationship roles 12 a,b and associated features18 a,b and interaction 14 abilities.

Therefore, relationships 12 and optional relationship roles 12 a,b canchange, as coordinated by the administration system 26, and in changingsome relationship features 18 and/or roles 12 a,b can supersede (eitherin whole or in part) one another. For example, two members 20 could bepaired 12 as Associates but then become closer and decide to becomepaired 12 as Colleagues. In becoming colleagues, their associaterelationship 12 could be superseded because all of the features andcapabilities 18 of the Associate relationship 12 could be within theColleague relationship 12.

Further, individual relationships 12 and the corresponding relationshiproles 12 a,b need to be able to grow, in order to provide for desiredricher (e.g. additional feature 18 supported) interaction(s) 14 betweenthe members 20 of the evolving/growing relationship 12. One mechanismprovided by the administration system 26 to support the evolution ofrelationships is the coordination of aggregate relationship pairs 6 thatcan involve multiple relationship sub-pairs 12. For example, two members20 could be in a colleague-colleague relationship pair 12, but also wantto engage in a customer-vendor relationship pair 12 as well as astudent-vendor relationship pair 12. The administration system 26facilitates the management of the associated roles 12 a,b as anaggregate role 8 and the associated features set 18 as an aggregatefeature set 4 by enabling individual relationship pairs 12 that havedifferent features and capabilities 18 to aggregate.

An example of relationship evolution between members 20 is Joe Smith M1goes to University to be a Doctor. While at University, the teachershave decided to use a valuable medical industry social CRMnetwork—administration system 26—to work with their students 20. One ofJoe's M1 professors is Dr. Jones M2. Joe M1 connects with Dr. Jones M2on the administration system 26 in a Student-Teacher relationship pairRP-ST. Joe M1 gets his residency at Toronto General, as shown in FIG. 12a. He leaves university to start his new full time position. In leavingschool, the system 26 asks him to confirm that his relationship pairRP-ST (as Student to Teacher) be cancelled or changed, shown deleted bystippled lines for R-T,F-T and R-S,F-S in FIG. 12 b.

Next, the final result of relationship evolution is shown in FIG. 12 b,where first Joe M1 requests, via a handshake 14, that Dr. Jones 20accept new relationship pair RP-AA—an Associate to Associate. Joe M1 isnow a physician at Toronto General, and he meets Dr. Jones M2 one day inthe hall as Dr. Jones M2 is now performing many consultations at thehospital. They M1,M2 end up being able to become closer, and are nowcolleagues. They change their administration system 26 via interactions14 with one another to reflect this, i.e. to add a colleague tocolleague pair RP-CC. Joe M1 decides he is no longer interested inworking with the providers, and interviews with AstraZeneca to work withtheir medical department. They accept that, and he moves to AZ. He keepshis Colleague to Colleague relationship pair RP-CC with Dr. Jones M2,but now also requests 14 that Dr. Jones M2 accept him as a Vendor for AVproducts, thus further evolving their relationship in the administrationsystem 26 to add a vendor-customer relationship pair RP-VCust.

In view of the above example, it is recognised that the individualrelationship pairs RP-AA, RP-VCust, RP-CC are aggregated to define thecorresponding aggregate relationship pair 6 (an aggregation of thedifferent individual relationship pairs 12) between the members M1,M2.Further, it is recognised that the corresponding aggregate role 8 is anaggregated combination of the individually defined roles 12 a,b (e.g.role R-A, R-A, R-V, R-Cust, R-C, R-C) of each of the individualrelationship pairs RP-AA, RP-VC, RP-CC, and the corresponding aggregatefeatures/capabilities 4 is an aggregated combination of the individuallydefined features/capabilities 18 a,b (e.g. features/capabilitiesC-A,C-A, C-V,C-Cust, C-C, C-C) of each of the individual relationshiproles 12 a.b. In other words, the administration system 26 provides fordefined interactions 14 between any paired members 20 based on theiraggregate features/capabilities 4 as defined via their correspondingaggregate role 8. For example, Joe M1 interacts 14 with Dr. Jones M2 intheir aggregate relationship pair 6 using any of the aggregatefeatures/capabilities 18. In view of the defined interactions 14facilitated by the system 26 via the relationship gate 150 (see FIG. 7),either of the members M1,M2 can recognise what individual role 12 a,b(and/or combined role 12 a,b) available in the aggregate role 8 that themember M1,M2 is using during the interactions 14, as any of theaggregate features/capabilities 4 can retain and/or combine theirindividual defined characteristic features/capabilities 18characteristics represented in the interactions 14.

Further, in view of the above, it is recognised that certain feature(s)18 can be such as but not limited to: unique (e.g. only provided) by aparticular role 12 a,b and therefore become additions/deletions to/fromthe existing/aggregate features 4 when the roles 12 a. b are aggregated(i.e. when a new role 12 a,b is added to existing role(s) 12 a,b oraggregate role 8 and/or existing role(s) 12 a,b is/are deleted/removedfrom the existing aggregate role 8 (or existing single role 12 a,b); canoverlap (e.g. be in common) between two or more roles 12 a,b andtherefore become redundant aggregate feature(s) 4 when the roles 12 a. bare aggregated; can be conflicting with other existing features 18 ofthe set of aggregate features 4 and therefore the new and/or existingfeatures 18 can be disabled/deleted from the aggregate features 4 whenthe roles 12 a. b are aggregated; can supersede or be superseded (e.g.either the new or existing feature is a preferred feature 18) overexisting/new feature(s) 18 in the aggregate features 4 and therefore thenon-preferred features new and/or existing features 18 can bedisabled/deleted from the aggregate features 4; or a combinationthereof.

Further, it is recognised that the process of aggregation performed bythe administration system 26 for example, to result in the aggregaterelationship pair 6 and associated optional aggregate role 8 andassigned aggregate features 4, can be defined by such as but not limitedto: the combining of a selected (e.g. by the member 20 and/or requested14 by another member 20) new optional role 12 a,b to an existingrelationship role 12 a,b or to two or more existing roles 12 a,b (e.g.to an existing aggregate role 8) of a relationship pair 12,6; thedeleting of a selected role 12 a,b from two or more existing roles 12a,b (e.g. to an existing aggregate role 8) of a relationship pair 6;and/or the amendment of an existing relationship role 12 a,b or of atleast one of two or more existing roles 12 a,b (e.g. to an existingaggregate role 8) of a relationship pair 12,6 through the combining withselected new role(s) 12 a,b and/or an existing aggregated role 8.

It is recognised that the content (e.g. text, image, video, enclosures,message type (email, telephone, text message, etc.), message enclosures,content size/amount/length) and/or format (e.g. form of the content suchas colour, font style, message priority, etc.) of the interactions 14can be defined by and their generation facilitated by the associatedfeatures/capabilities 18 a,b (e.g. of the optional role 12 a,b or asshared by the members 20 of the pair 12) that the member 20 isusing/operating under in the administration system 26 with selected(active and/or passive) other members 20. It is also recognised that thecontent and/or form of the interactions 14 can be defined using acombination of different roles 12 a,b and their associated features 18a,b in view of aggregation of relationship pairs 12. Therefore, theaggregate features 4 of the aggregate role 8 can cooperate togetherand/or separately, as selected by the respective member 20 to generate14 and/or to respond/reply 14 to communications over the network 14between member(s) 20 that are part of the member aggregate relationshippair 4 governed by the aggregate roles 8 a,b assigned to the members 20of the aggregate relationship pair 4.

For example, when Joe M1 asks 14 Dr. Jones M2 to dinner, thecharacteristics (e.g. text, image content and/or format) of theinteraction 14 can be defined by the particular features/capabilities 18Joe M1 is using from his aggregate role 8 of the aggregate relationshippair 6 with Dr. Jones M2. For instance, Joe M1 can send an email 14 toDr. Jones M2 requesting a meeting at a corresponding time and place.Based on the use of certain individual role(s) 12 a,b in the aggregaterole 8, by Joe M1, when generating the email 14, Joe M1 can affect theperceived tone (e.g. business, personal, or a combination thereof) ofthe email 14 by selecting certain features/capabilities 18 a,bassociated with selected roles 12 a,b of his aggregated role 8 with Dr.Jones M2. For example, Joe M1 can select in communication withinteraction 14 building capabilities of the administration system 26(e.g. via browser as a thin client of the administration system 26 as aWeb service), and/or via an administration system module/application 27installed on his device 101, see FIG. 2, (e.g. as a thick client of theadministration system 26), the particular roles R-V,R-C and thereforehave available all of the content/format features C-V,C-C to generatethe email 14. In this case, Joe M1 can include in the email 14 vendordetails (via the selected individual capabilities C-V of the selectedindividual role R-V) of his products with marketing and/or ordermaterials (as email enclosures) and can also have the email 14 typefoiniatted (via the selected individual capabilities C-C of the selectedindividual role R-C in the role 8) to be perceived as a colleaguemeeting invitation. This would provide for Dr. Jones M2 to understandthat the proposed meeting will be a combination of business and personalinteraction between them, e.g. a soft sell environment with potentialfor extended interaction in the colleague context. On the contrary, JoeM1 can include in the email 14 only vendor details (via the selectedindividual capabilities C-V of the selected individual role R-V in therole 8) of his products with marketing and/or order materials (as emailenclosures) with corresponding formatting (via the selected individualcapabilities C-C of the selected individual role R-C in the role 8).This would provide for Dr. Jones M2 to understand that the proposedmeeting will be a strictly business interaction between them, e.g. aharder sell environment with little/no time for extended interaction inother role 12 a,b contexts of the aggregate role 8 of the aggregaterelationship 6. It is recognised that both Dr. Jones M2 and Joe M1 arecognizant of the extents (i.e. list of possible individual roles 12 a,band associated individual features 18 a,b) of their aggregaterelationship pair 6.

As well, further to the above example, Dr. Jones M2 can also include inhis response communication 14 (e.g. email and/or telephone call) theappropriate type of response as dictated by the individual role(s) 12a,b used to generate the original email 14. For example, in the strictbusiness sense, the relationship gate 150 may disallow returncommunication 14 (to the email 14) in the form of a telephone call, asthis would not be available as a feature/capability 18 in a customerrole R-Cust in response to received product solicitation emails 14 (i.e.Joe M1 only used his role R-V to generate the email 14). On the otherhand, in the event where Joe M1 used his role R-V to generate the email14 along with his role R-C as part of his aggregate role 8, therelationship gate 150 could allow Dr. Jones M2 to informally reply 14 tothe original email 14 using a telephone call 14 as part of the featuresC-C afforded by Dr. Jones M2 role R-C of his respective aggregate role8.

In view of FIGS. 1 and 12 a,b and the above evolution example, it isrecognised that aggregation of relationship pair 12 types (i.e. anymember 20 assuming the roles 12 a and associated features/capabilities18 a of a plurality of relationship pair types 12) can be used torepresent electronically the definition of the Aggregate relationshiprole 8 for a member 20, representing the composite/aggregation ofindividually defined roles 12 a,b that a member 20 has between two ormore other members 20 of the administration system 26. Accordingly, theAggregate relationship role 8 provides for any member 20 to evolve theiraggregated relationship pairs 12 over time as an assembly/combination ofseparate parts/portions of features/capabilities 18 a defined for anumber of respective different defined relationship roles 12 a of anumber of different relationship pair 12 types. It is recognised thatthe roles 12 a,b as part of the aggregate relationship role 8 can affectthe growth and/or shrinkage in size and/or effect of the capabilities,features, and restrictions 18 associated with each overall aggregaterelationship 12 (i.e. a combination/aggregation of differentrelationship pairs 12) between pairs of members 20. Therefore, theprovision and coordination of aggregate relationship pairs 6 by theadministration system 26 between pairs of members 20 can provide forincremental increase/decrease in the size and/or effect of theassociated roles 12 a,b, and corresponding features/capabilities 18 a,bas a collection from separate/individual defined roles 12 a,b andcorresponding features/capabilities 18 a,b aggregated within theaggregate relationship pair 6.

As an alternative embodiment, it is also recognised that the definedonline existing relationship 12 between a first member 20 and a secondmember 20 can be defined by a plurality of existing relationshipfeatures 18 for use in managing network interaction 14 on thecommunications network 11 between the first member 20 and the secondmember 20. The relationship features 18 are characteristic of therelationship 12, such that at least one of the correspondingrelationship features 18 of the relationship 12 is used to define aspermitted at least one of the network interaction 14 type, the networkinteraction content, or the network interaction format. It is recognisedthat the relationship features 18 can be between the first member 20 andthe second member 20 (i.e. each of the members 20 do not have a definedrelationship role 12 a,b, in the relationship 12). Or, as furtherdiscussed above, it is recognised that a first portion of therelationship features 18 a characterizes the first relationship role 12a and a second portion of the relationship features 18 b characterizesthe second relationship role 12 b, such that the first relationship role12 a and the second relationship role 12 b are part of the relationshipdefined as the relationship pair 12 between the first and second members20. In other words, the aggregate relationship pair 12, described aboveby example only, can be administered by the administration system 26 asa role less relationship 12, such that the relationship features 18 areshared between the members 20 for managing their inter-member 20interactions 14.

Relationship Engine of the Administration System 26

Referring to FIGS. 1 and 13, shown is a relationship network environment10 for facilitating communications 14 between members and nonmembers20,24 (e.g. using a computing device 101—see FIG. 2) via therelationship administration system 26. Relationship data 15 ismaintained by a relationship engine 100 of the system 26 for one or morepairs 12 defined for a pair of the members/nonmembers 20,24. The mode,format, and/or information content of the communications 14 between themembers/nonmembers 20,24 may be monitored or otherwise structured by therelationship administration system 26 in view of the particularfeatures/capabilities defined in the relationship data 15 of the pair(s)12 defined for the member pair. The relationship engine 100 provides forinitializing, maintaining, and modifying the defined pair(s) 12associated with a selected pair of the members 20, as well as managingthe interactions 14 based on the data 15.

For example, evolving a defined online existing relationship 12 betweena first member 20 and a second member 20 is performed by the engine 100,such that the online existing relationship 12 is defined by a pluralityof existing relationship features 18 for use in managing networkinteraction 14 on a communications network 11 between the first member20 and the second member 20. The engine 100 facilitates receiving by aselection module 162 a new online relationship 12 (for example submittedby one of the members 20) having new relationship features 18, such thatthe new features 18 are different from the existing relationshipfeatures 18. The new relationship features 18 are characteristic of thenew relationship 12. The engine 100 aggregates the existing relationshipfeatures 18 (and optionally for the aggregate role 8 by aggregating thenew and existing roles 12 a,b) and the new relationship features 18 byan aggregation module 160 as aggregate relationship features 4, whichare a combination of the existing relationship features 18 and the newrelationship features 18, in order to define the aggregate relationship6. The engine 100 stores the aggregate relationship features 4 in astorage 210 of the administration system 26 as relationship data 15representing the aggregate relationship 6 defined by the relationshipfeatures 4 for example by the aggregator module 160.

A further optional operation is by done a banding module 164 fordefining a minimum number (e.g. sets 22,23) of aggregate features 4 ofthe aggregate relationship 6 that must be maintained, as discussedabove. A further optional operation is by a role module 166 for definingthe aggregate role 8 a,b for each of the members 20 of the aggregaterelationship 6 that is confirmed by the member (s) 20. It is alsorecognised that the role module 166 can be used to define anydirectional and inherent/passive nature of the roles 8 a,b.

Further, the engine 100 has the relationship gate module 150 configuredfor accessing the relationship data 15 in order to determine whether aselected network interaction 14 from one of the members 20 is permittedin view of at least one of the corresponding aggregate relationshipfeatures 4 of the aggregate relationship 6. The relationship gate module150 also facilitates the selected network interaction 14 between themembers 20 when determined as permitted, such that the at least one ofthe corresponding aggregate relationship features 4 of the aggregaterelationship 6 is used to define as permitted at least one of thenetwork interaction 14 type, the network interaction content, or thenetwork interaction format.

It is also recognized that multimember pairings 12 could be implementedby the system 26, for example where each of a plurality of members ispaired to a respective member (e.g. a many to one pairing) or arespective member is paired to a plurality of members (e.g. a one tomany pairing). This type of pairing provides for the setup of groupsettings, such as a plurality of customers that are serviced by avendor, a plurality of vendors that are selected to service a particularcustomer, a manager that has a number of employees, etc. In this manner,communications 14 between the members in group settings can be performedin parallel, such that an offer from one vendor can be communicated 14simultaneously to the each of the plurality of customers associated withthe vendor, via the respective defined vendor customer role pairs 12between the vendor and each of the customers of the plurality ofcustomers of the system 26. Also, in the case of multiple vendors for aparticular customer, each of the vendors could be made aware (via thesystem 26) of an offer proposed by one of the vendors to the customer(e.g. in a open bid process in a Request for Proposal situation).Further, it is also recognized that a many to many member group can beset up, such as in the case of a group of friends, a group ofcolleagues, etc. In this manner, communications 14 sent to one of themembers of the group would be communicated to each of the other membersof the group.

However, in each of the above multimember pairing examples, there canexists defined role 12 a,b between any two member pair of the pluralityof members 20, i.e. in the colleague group example, each of the membersof the group would have a colleague-colleague defined role 12 a,b witheach of the other members of the group. A further embodiment is wherethere is a relationship defined as a three (or more) person “pairing”such that there are three or more roles 12 a,b,c, with associatedfeatures/capabilities 18 a,b,c to define the complete set ofinteractions 14 between the multi-person “pairing” 12. In this manner,each of the members of the multi-person pairing (also know as a memberset) has a subset of the total features/capabilities 18 a,b,c (somefeatures/capabilities 18 a,b,c can be overlapping between the members ofthe member set. For example, a relationship member set of a teacher, atutor, and a student can be implemented in the system 26, such that eachmember of the member set is connected to each other as defined by theindividual relationship roles defined in their relationship data 15. Forexample, the teacher, tutor, student combination could contain theindividual pairings 12 of student-teacher, teacher-student,student-tutor, tutor-student, teacher-tutor, and tutor-teacher, suchthat each of the roles 12 a,b,c of the member set pairing 12 would havethe associated features/capabilities 18 a,b,c. For example, the tutorand the teacher could share 14 exam results and other evaluationcriteria/comments of the student (which are blocked 14 from view fromthe student), the tutor could receive and respond 14 to laboratoryquestions from the student, however these questions would not becommunicated 14 to the teacher until first reviewed/commented on by thetutor, etc.

In the manner as discussed above by example, the format, content, mode,and other features/capabilities of the communications 14 (includinginformation visible on the Web page/profile page 11 of the memberaccount) between members is monitored and/or otherwisemaintained/structured by the system 26.

The following is a list, for example only, of the configuration of therelationship data 15 between any pair of members of the system 26:

-   -   Users choose relationships (i.e. pair(s) 12) to have with        another users;    -   Some relationships are aggregated/combined/Some are        hierarchical;    -   Relationships can be removed/downgraded/upgraded;    -   A relationship connection can use two one way connections 12        a,b, e.g. the vendor has a vendor customer connection 12 a with        the customer and the customer has a customer-vendor connection        12 b with the vendor). Therefore, the user offering any        relationship uses a complimentary relationship in reverse. So to        be in a relationship, the other user accepts the complimentary        relationship to have back. To accommodate the creation of ‘two        relationships’, each user adopts a relationship role 12 a,b in        any two way relationship 12 (also would apply in member sets        having more than two members);    -   Relationships are impacted by time, and can require        checks/changes/upgrades/downgrades/etc;    -   Events may trigger relationship checks/changes;    -   User roles may impact relationship;    -   User relationships with other users/organizations may impact        potential for relationships with another user;    -   User may alter, within limits, relationship permissions by        customizing the available customizable features/capabilities of        the defined role pairing 12. (There can be minimum permissions        and maximum permissions associated with each relationship, so as        to maintain a band of commonality with each relationship so        users become used to what it means to be involved in that        relationship.);    -   Capability to start/maintain a relationship may be impacted by:        -   User role of Initiator        -   User role of Receiver        -   Service package of Initiator        -   Service package or Receiver        -   Organization Environment of Initiator        -   Organization Environment of Receiver;    -   Connections or “pipes”(e.g. one-way connection of the two way        relationship) may be used to transfer information/features;    -   Some “pipes” may be active. Some may be passive; and    -   Some relationship pipes are always in place, depending on the        user role. (For example, a base user always has ‘Public’ pipes        in place displaying a limited amount of information to the        public).

Operation of the System 26

Referring to FIGS. 1, 12 b, 13, and 14, a method 300 for evolving adefined online existing relationship 12 between a first member 20 and asecond member 20 is provided, such that the online existing relationship12 is defined by a plurality of existing relationship features 18 foruse in managing network interaction 14 on a communications network 11between the first member 20 and the second member 20. The method 300includes: step 302 receiving by the selection module 162 a new onlinerelationship 12 having new relationship features 18 such that the newfeatures 18 are different from the existing relationship features 18,the new relationship features 18 being characteristic of the newrelationship 12; step 304 aggregating the existing relationship features18 (and optionally for the aggregate role 8) and the new relationshipfeatures 18 by the aggregation module 160 as aggregate relationshipfeatures 4 as a combination of the existing relationship features 18 andthe new relationship features 18 in order to define an aggregaterelationship 6; step 306 storing the aggregate relationship features 4in a storage 210 of the administration system 26 as relationship data 15representing the aggregate relationship 6 defined by the relationshipfeatures 4; and step 308 of accessing the relationship data 15 by therelationship gate 150 in order to determine whether a selected networkinteraction 14 from one of the members20 is permitted in view of atleast one of the corresponding aggregate relationship features 4 of theaggregate relationship 6 and facilitating the selected networkinteraction 14 between the members 20 when determined as permitted, suchthat the at least one of the corresponding aggregate relationshipfeatures 4 of the aggregate relationship 6 is used to define aspermitted at least one of the network interaction 14 type, the networkinteraction content, or the network interaction format.

A further optional step 310 is by a banding module 164 for defining aminimum number of features 4 of the relationship 6 that must bemaintained. A further optional step 312 is by a role module 166 fordefining the aggregate role 8 a,b for each of the members 20 of therelationship 6 that must be confirmed by the member(s) 20. It is alsorecognised that the role module 166 can be used to define anydirectional and inherent/passive nature of the roles 8 a,b.

Computing Devices 101

Referring to FIGS. 1 and 2, each of the above-described members 20 andadministration systems 26 can be implemented on one or more respectivecomputing device(s) 101. The devices 101 in general can include anetwork connection interface 200, such as a network interface card or amodem, coupled via connection 218 to a device infrastructure 204. Theconnection interface 200 is connectable during operation of the devices101 to the network 11 (e.g. an intranet and/or an extranet such as theInternet), which enables the devices 101 to communicate with each otheras appropriate. The network 11 supports the communication 14 of the databetween the administration system 26 and members 20, and also supportsthe communication 14 of the data between the members 20.

Referring again to FIG. 2, the devices 101 can also have a userinterface 202, coupled to the device infrastructure 204 by connection222, to interact with a user (e.g. vendor 20, customer 20, nonmember 20,etc.). The user interface 202 can include one or more user input devicessuch as but not limited to a QWERTY keyboard, a keypad, a track wheel, astylus, a mouse, a microphone and the user output device such as an LCDscreen display and/or a speaker. If the screen is touch sensitive, thenthe display can also be used as the user input device as controlled bythe device infrastructure 204. For example, the user interface 202 forthe devices 101 used by the members 20 can be configured to interactwith the members 20 web browsers (applications 16) to access 14 themember information 15 available on the websites/accounts 9 of themembers 20. For the devices 101 used by the members 20, the userinterfaces 202 can be used to access the administration system 26 (e.g.via a website) to register with the system 26 (i.e. set up/modify theiraccount) as well as to provide information for display on their account9. For the devices 101 used by the administration system 26 (e.g. usingthe relationship engine 100), the user interfaces 202 can be used to theadministration to configure the relationship data 15 of memberpairing(s) 12 based on information and/or registration data of themembers 20.

Referring again to FIG. 2, operation of the device 101 is facilitated bythe device infrastructure 204. The device infrastructure 204 includesone or more computer processors 208 and can include an associated memory210 (e.g. a random access memory) for storing of relationship data 15and for processing communications 14 communicated between the members 20and between the administration system 26 and the members 20. Thecomputer processor 208 facilitates performance of the device 101configured for the intended task (e.g. members 20, administration system26) through operation of the network interface 200, the user interface202 and other application programs/hardware 16 of the device 101 byexecuting task related instructions, These task related instructions canbe provided by an operating system, and/or software applications 16located in the memory 210, and/or by operability that is configured intothe electronic/digital circuitry of the processor(s) 208 designed toperform the specific task(s). Further, it is recognized that the deviceinfrastructure 204 can include a computer readable storage medium 212coupled to the processor 208 for providing instructions to the processor208 and/or to load/update client applications 16. The computer readablemedium 212 can include hardware and/or software such as, by way ofexample only, magnetic disks, magnetic tape, optically readable mediumsuch as CD/DVD ROMS, and memory cards. In each case, the computerreadable medium 212 may take the form of a small disk, floppy diskette,cassette, hard disk drive, solid state memory card, or RAM provided inthe memory module 210. It should be noted that the above listed examplecomputer readable mediums 212 can be used either alone or incombination. For example, the applications 16 can include browsers usedby the members 20 to access the Web site of the administration system 26and/or to communicate 14 information between members 20 of the system 26

Further, it is recognized that the computing devices 101 can include theexecutable applications 16 comprising code or machine readableinstructions for implementing predetermined functions/operationsincluding those of an operating system, relationship configurationsystem(s), for example, in response to user command or input. Theprocessor 208 as used herein is a configured device and/or set ofmachine-readable instructions for performing operations as described byexample above. As used herein, the processor 208 may comprise any one orcombination of, hardware, firmware, and/or software. The processor 208acts upon information by manipulating, analyzing, modifying, convertingor transmitting information for use by an executable procedure or aninformation device, and/or by routing the information with respect to anoutput device. The processor 208 may use or comprise the capabilities ofa controller or microprocessor, for example. Accordingly, any of thefunctionality (e.g. engine 100) provided by the systems and process ofFIGS. 1,2,3 may be implemented in hardware, software or a combination ofboth. Accordingly, the use of a processor 208 as a device and/or as aset of machine readable instructions is hereafter referred togenerically as a processor/module for sake of simplicity. Further, it isrecognized that the administration system 26 can include one or more ofthe computing devices 301 (comprising hardware and/or software) forimplementing the engine 100, as desired.

It will be understood that the member 20 client computing devices 101may be, for example, personal computers, personal digital assistants,mobile phones, and content players. Server computing devices 101 (e.g.for the administration system 26 and/or the member 20) may additionallyinclude a secondary storage element such as the memory (e.g. database).Each server, although depicted as a single computer system, may beimplemented as a network of computer processors, as desired.

While illustrative embodiments of the invention are disclosed herein, itwill be appreciated that numerous modifications and other embodimentsmay be devised by those of ordinary skill in the art and the inventionis not to be understood to be limited to such illustrated embodiments.Therefore, it will be understood that the appended claims are intendedto cover all such expedient modifications and embodiments that comewithin the spirit and scope of the present invention, including thosereadily attainable by those of ordinary skill in the art from thedisclosure set forth herein, or by routine experimentation therefrombased on the guidance herein.

1. A method for evolving a defined online existing relationship betweena first member and a second member, the online existing relationshipdefined by a plurality of existing relationship features for use inmanaging network interaction on a communications network between thefirst member and the second member, the method comprising: receiving anew online relationship having new relationship features such that thenew features are different from the existing relationship features, thenew relationship features being characteristic of the new relationship;aggregating the existing relationship features and the new relationshipfeatures as aggregate relationship features a combination of theexisting relationship features and the new relationship features inorder to define an aggregate relationship; storing the aggregaterelationship features in a storage as relationship data representing theaggregate relationship defined by the relationship features; andaccessing the relationship data in order to determine whether a selectednetwork interaction from one of the members is permitted in view of atleast one of the corresponding aggregate relationship features of theaggregate relationship, and facilitating the selected networkinteraction between the members when determined as permitted; whereinsaid at least one of the corresponding aggregate relationship featuresof the aggregate relationship is used to define as permitted at leastone of the network interaction type, the network interaction content, orthe network interaction format.
 2. The method of claim 1, wherein theaggregate relationship features are shared between the first member andthe second member.
 3. The method of claim 2, wherein a first portion ofthe aggregate relationship features is assigned to an aggregate firstrelationship role of the aggregate relationship for the first member anda second portion of the aggregate relationship features is assigned toan aggregate second relationship role of the aggregate relationship forthe second member.
 4. The method of claim 3, wherein the aggregate firstrelationship role and the second aggregate relationship role aredifferent, such that the first portion of the aggregate relationshipfeatures characterizes the aggregate first relationship role and thesecond portion of the aggregate relationship features characterizes theaggregate second relationship role, such that the aggregate firstrelationship role and the aggregate second relationship role are part ofthe aggregate relationship defined as an aggregate relationship pairbetween the first and second members.
 5. A method for evolving a definedonline existing relationship pair between a first member and a secondmember, the online existing relationship pair defined by a firstexisting relationship role assigned to the first member having aplurality of first existing role features for use in managing networkinteraction on a conununications network between the first member andthe second member, and a second existing relationship role assigned tothe second member having a plurality of second existing role featuresfor use in managing the network interaction between the first member andthe second member, the method comprising: receiving a new onlinerelationship pair having a new first relationship role and a second newrelationship role, such that the corresponding first new role featuresand the second new role features are different from the first existingrole features and the second existing role features, the first new rolefeatures and second new role features being characteristic of the newrelationship pair; aggregating the first existing role features and thefirst new role features as aggregate first role features being acombination of the first existing role features and the first new rolefeatures in order to define an aggregate first role; aggregating thesecond existing role features and the second new role features asaggregate second role features being a combination of the secondexisting role features and the second new role features in order todefine an aggregate second role; storing the aggregate first role andthe aggregate second role with their associated aggregate features in astorage as relationship data representing an aggregate relationship pairdefined by the aggregate roles and their corresponding aggregate rolefeatures; and accessing the relationship data in order to determinewhether a selected network interaction from one of the members ispermitted in view of at least one of the corresponding aggregate role oraggregate role features of at least one of the aggregate first role oraggregate second role of the aggregate relationship pair, andfacilitating the selected network interaction between the members whendetermined as permitted; wherein said at least one of the correspondingaggregate role or aggregate role features of at least one of theaggregate first role or aggregate second role of the aggregaterelationship pair is used to define as permitted at least one of thenetwork interaction type, the network interaction content, or thenetwork interaction format.
 6. The method of claim 5, wherein the stepof aggregating the first existing and first new role features involvesthe addition of a new feature from the first new role features to thefirst existing role features.
 7. The method of claim 5, wherein the stepof aggregating the first existing and first new role features involvesthe deletion of an existing feature from the existing role features. 8.The method of claim 5, wherein the step of aggregating the firstexisting and first new role features involves the substitution of a newfeature from the first new role features exchange an existing feature ofthe existing role features.
 9. The method of claim 6, wherein thenetwork interaction is selected from the group comprising: a networkmessage and a network action associated with a profile of one of themembers.
 10. The method of claim 6 further comprising the step ofdefining a minimum number of the existing first role features to remainas part of the aggregate first role features.
 11. The method of claim 10further comprising the step of defining a minimum number of the newfirst role features to become part of the aggregate first role features.12. The method of claim 10 further comprising the step of defining inthe relationship data that the aggregate relationship pair is an activerelationship pair that requires formal acceptance by the second memberof the new second relationship role.
 13. The method of claim 10 furthercomprising the step of defining in the relationship data that theaggregate relationship pair is a passive relationship pair that does notrequire formal acceptance by the second member of the new secondrelationship role.
 14. The method of claim 10 further comprising thestep of defining the first new relationship role and the second newrelationship role as directional roles, such that the first member mustassume the first new relationship role in order for the second member toassume the second new relationship role.
 15. The method of claim 14,wherein the first new role features and the second new role features aredifferent from one another
 16. The method of claim 6 further comprisingthe step of defining in the relationship data that the aggregaterelationship pair is an active relationship pair that requires formalacceptance by the second member of the new second relationship role. 17.The method of claim 6 further comprising the step of defining in therelationship data that the aggregate relationship pair is a passiverelationship pair that does not require formal acceptance by the secondmember of the new second relationship role.
 18. The method of claim 10further comprising the step of defining the first new relationship roleand the second new relationship role as directional roles, such that thefirst member must assume the first new relationship role in order forthe second member to assume the second new relationship role.
 19. Themethod of claim 18, wherein the first new role features and the secondnew role features are different from one another
 20. A method forevolving a defined online existing relationship pair between a firstmember and a second member, the online existing relationship pairdefined by a plurality of existing relationship features for use inmanaging network interaction on a communications network between thefirst member and the second member, the method comprising: receiving anew online relationship pair having corresponding new relationshipfeatures different from the existing relationship features, the newrelationship features being characteristic of the new relationship pair;combining the existing relationship features and the new relationshipfeatures to generate combined relationship features by adding a newfeature from the new relationship features to the existing relationshipfeatures, such that a minimum number of the existing relationshipfeatures remain as part of the combined relationship features; storingthe combined relationship features in a storage as relationship datarepresenting the new relationship pair for the members defined by thecorresponding respective combined relationship features; and accessingthe relationship data in order to determine whether a selected networkinteraction from one of the members is permitted in view of at least oneof the corresponding combined relationship features, and facilitatingthe selected network interaction between the members when determined aspermitted; wherein at least one of the corresponding combinedrelationship features of the new relationship pair is used to define aspermitted at least one of the network interaction type, the networkinteraction content, or the network interaction format.
 21. A method forevolving a defined online existing relationship pair between a firstmember and a second member, the online existing relationship pairdefined by a first existing relationship role assigned to the firstmember having a plurality of first existing role features for use inmanaging network interaction on a communications network between thefirst member and the second member, and a second existing relationshiprole assigned to the second member having a plurality of second existingrole features for use in managing the network interaction between thefirst member and the second member, the method comprising: receiving anew online relationship pair having corresponding first new rolefeatures and the second new role features different from the firstexisting role features and the second existing role features, the firstnew role features and second new role features being characteristic ofthe new relationship pair; combining the first existing role featuresand the first new role features to generate combined first role featuresby adding a new feature from the first new role features to the firstexisting role features, such that a minimum number of the existing firstrole features remain as part of the combined first role features;combining the second existing role features and the second new rolefeatures to generate combined second role features by adding a newfeature from the second new role features to the second existing rolefeatures, such that a minimum number of the existing second rolefeatures remain as part of the combined second role features; storingthe combined role features in a storage as relationship datarepresenting the new relationship pair for the members defined by thecorresponding respective combined role features; and accessing therelationship data in order to determine whether a selected networkinteraction from one of the members is permitted in view of at least oneof the corresponding combined role features, and facilitating theselected network interaction between the members when determined aspermitted; wherein at least one of the corresponding combined rolefeatures of the new relationship pair is used to define as permitted atleast one of the network interaction type, the network interactioncontent, or the network interaction format.
 22. The method of claim 21further comprising the step of defining a minimum number of the newfirst role features to become part of the combined first role features.23. The method of claim 21 further comprising the step of defining aminimum number of the new second role features to become part of thecombined second role features.
 24. A method for defining an onlinerelationship pair between a first member and a second member, therelationship pair including a first relationship role assigned to thefirst member having a plurality of first role features for use inmanaging network interaction on a communications network between thefirst member and the second member, and a second relationship roleassigned to the second member having a plurality of second role featuresfor use in managing the network interaction between the first member andthe second member, the method comprising: assigning the firstrelationship role to the first member such that the first role featuresare characteristic of the first relationship role; assigning the secondrelationship role to the second member such that the second rolefeatures are characteristic of the second relationship role, such thatthe second member must confirm the second relationship role in order forthe first member to be able to use the first relationship role in thenetwork interaction between the first and second members; storing thefirst role and the second role with their associated role features in astorage as relationship data representing the relationship pair; andaccessing the relationship data in order to determine whether a selectednetwork interaction from one of the members is permitted in view of atleast one of the corresponding relationship roles or role features of atleast one of the first role or second role of the relationship pair, andfacilitating the selected network interaction between the members whendetermined as permitted; wherein said at least one of the correspondingrelationship roles or role features of at least one of the first role orsecond role of the relationship pair is used to define as permitted atleast one of the network interaction type, the network interactioncontent, or the network interaction format.